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This  report  summarizes  the  results  of  a  study  into  the  design  of 
compilers  that  are  more  easily  retargetted  than  compilers  of  today. 

Prime  emphasis  is  on  the  use  of  machine  description  language  to  define 
the  •’target*  machine,  and  a  common  Intermediate  language  to  *target  to.* 
The  goal  was  to  define  the  characteristics  for  a  tool  which  would  take 
the  description  of  a  computer  as  input  and  output  a  code  generator  for 
that  machine. 
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SUMMARY 


Software  portability  is  one  of  the  key  methods  of  combating  the 
software  crisis  brought  on  by  plummetting  hardware  costs  and  prolifera¬ 
tion  of  new  computer  designs.  Use  of  High  Order  Languages  (HOL’s) 
assist  this  effort,  as  long  as  the  corresponding  compilers  can  be  easily 
generated  to  match  a  given  HOL  to  any  new  machine  architecture.  The 
Retargetable  Compiler  is  such  a  compiler,  in  which  an  HOL  program  may 
be  reduced  to  high  quality  code  for  a  given  machine.  The  compiler  should 
be  automatically  produced  from  a  formal  description  of  the  machine. 

In  this  report  we  will  review  the  current  level  of  technology  cover¬ 
ing  compiler  theory,  and  especially  compiler-compiler  theory.  We  will 
establish  bounds  on  the  kinds  of  languages  and  machines  we  intend  to  be 
able  to  handle  with  our  design,  and  finally  we  will  present  a  design 
for  a  retargetable  compiler  system  based  on  our  research  performed  un¬ 
der  this  contract. 
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EVALUATION 


The  objective  of  this  effort  was  to  develop  design  recommendations 
for  a  tool  to  automatically  build  the  code  generator  portion  of  a  com¬ 
piler  (automatically  retarget)  from  a  formal  description  of  the  target 
machine.  Such  a  tool  would  enable  the  use  of  manpower  efficient  high 
order  computer  programming  languages  on  more  Air  Force  software  system 
developments.  Since  software  development  and  maintenance  is  labor 
intensive,  this  effort  is  obviously  responsive  to  RADC  TP0-R5A,  "Soft¬ 
ware  Cost  Reduction". 

This  effort  met  the  objective  with  a  thoroughly  analyzed  set 
of  recommendations  for  such  a  tool.  The  present  plan  is  to  develop  a 
"retargetable"  compiler  for  the  new  common  DOD  programming  language 
known  as  Ada.  It  is  hoped  that  the  retargetable  compiler  for  Ada  can 
commence  development  in  FY82. 

SAMUEL  A.  DI  NITTO,  JR 
Project  Engineer 
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1 .  INTRODUCTION 


In  this  section,  we  discuss  the  current  level  of  compiler,  tech¬ 
nology,  including  its  strengths  and  weaknesses,  as  well  as  our  goals 
under  the  Retargetable  Compiler  project. 

1 . 1  The  Current  State  of  Compiler  Technology 

Since  the  introduction  of  high  order  languages,  both  the  theory 
and  practice  of  language  compilation  have  been  advanced.  One  of  the 
more  significant  factors  in  this  advancement  is  the  use  of  meta- lan¬ 
guages  to  describe  the  syntax  of  the  target  language.  Two  beneficial 
effects  have  resulted.  First,  the  front-end  parts  of  compilers,  which 
decompose  the  lexical/syntactic  structure  of  the  source  language,  have 
been  generalized  to  the  point  that  they  can  operate  directly  from  the 
formal  specification  of  the  source  language.  Thus,  source  decomposi¬ 
tion  is  no  longer  considered  a  major  hurdle  in  compiler  development. 

The  second  benefit  of  the  use  of  meta-languages  is  simplification  of 
programming  language  through  a  tendency  to  use  fewer  and  more  system¬ 
atic  syntactic  structures.  While  this  has  only  a  quantitative  effect 
on  compilers,  it  is  a  significant  advancement  in  practical  software 
development . 

Success  with  formalization  of  language  syntax  has  led  to  the  de¬ 
sire  for  some  formalizations  of  semantics  and  program  flow.  Making 
use  of  these  formalizations,  the  compilation  process  has  been  evolved 
into  a  two  step  process,  in  which  the  source  program  is  first  trans¬ 
lated  into  an  intermediate  language,  and  then  into  the  target  language. 

The  intermediate  language  is  designed  to  express  only  the  semantics 
of  the  program,  thereby  isolating  the  syntax  of  the  source  language 
from  that  of  the  target  language.  There  is  a  large  variety  of  global 
and  local  optimizations  which  are  most  conveniently  performed  on  the 
intermediate  language  form  of  a  program.  These  optimizations  (which 
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should  more  properly  be  called  "improvements")  are  transformations  of 
the  program  which  do  not  alter  the  semantics  of  the  program  as  speci¬ 
fied  by  its  source  language  form,  and  which  reduce  some  compile  time 

measure  of  program  cost.  The  cost  function  to  be  reduced  is  usually 

* 

program  size,  estimated  program  speed,  or  a  combination.  The  optimiza¬ 
tions  most  easily  performed  on  the  intermediate  language  program  (before 
code  generation)  are  often  called  "machine  independent  optimizations". 
They  can  be  performed  regardless  of  the  target  machine,  although  their 
desirability  may  depend  on  certain  aspects  of  the  target  machine. 

There  is  a  large  body  of  theory  on  obtaining  and  using  the  data  flow 
information  on  which  global  optimization  is  based,  and  a  less  compre¬ 
hensive  though  growing  body  of  experience  in  using  machine  independent 
optimizations. 

1 . 2  Problem  Areas  in  Compiler  Technology 

After  a  source  program  has  undergone  semantic  analysis  and  ma¬ 
chine  independent  optimization,  it  must  be  translated  into  the  target 
language.  This  translation  is  from  an  intermediate  language,  which 
expresses  the  program  being  compiled.  The  most  common  approach  is  to 
generate  target  code  based  upon  the  elements  of  the  intermediate  lan¬ 
guage,  with  consideration  given  to  the  context  of  each  such  element. 

This  approach,  termed  the  "ad  hoc"  approach,  is  basically  a  heuristic 
approach  as  opposed  to  one  based  strictly  on  a  theory  of  code  genera¬ 
tion.  There  is  more  theory  known  concerning  register  allocation  stra¬ 
tegies,  but  up  to  this  point  the  theory  is  applicable  only  for  special 
cases,  such  as  single  register  machines  or  single  code  blocks  without 
loops.  The  practical  algorithm  for  register  allocation  are  again 
heuristics.  This  lack  of  underlying  theory  is  a  major  obstacle  to 
automatic  generation  of  the  register  allocation  and  code  generation 
phases  of  a  compiler. 

Another  area  in  which  there  is  plenty  of  information  and  little 
organization  is  target  dependent  optimization.  This  includes  all 
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transformations  applied  to  either  intermediate  or  target  forms  which 
can  be  shown  to  constitute  "improvement"  of  the  program  only  when 
characteristics  of  the  target  are  given.  Most  of  these  optimizations 
are  obvious,  and  of  direct  benefit  in  reducing  target  program  size  or 
execution  time,  but  they  all  seem  to  be  unique  in  comparison  with  each 
other.  They  do  not  form  categories  or  patterns  within  a  coherent 
theory.  Each  is  its  own  category,  and  each  is  either  completely  appli¬ 
cable  or  completely  in-applicable  for  each  target  machine.  If  a  fully 
generalized  theory  of  code  generation  existed,  it  would  have  to  be 
sufficiently  adaptive  to  the  target  architecture  that  it  would  pro¬ 
bably  eliminate  the  need  for  our  present  distinction  between  code  gen¬ 
eration,  register  allocation,  and  target  dependent  optimization. 

1 . 3  Other  Compiler  Development  Problems 

In  developing  any  software  project,  it  is  valuable  to  have  not 
only  a  clean  set  of  objectives,  but  also  a  way  of  measuring  progress 
toward  those  objectives.  A  compiler  may  well  be  an  extreme  case  in 
this  regard.  Compilers  possess  many  characteristics,  and  meeting  an 
objective  relative  to  one  characteristic  often  conflicts  with  others. 

In  the  course  of  developing  a  compiler,  these  conflicts  must  be  worked 
out  through  compromise.  Such  compromises  can  be  made  rationally  only 
if  the  developer  knows  the  degree  to  which  he  is  trading  one  thing 
for  another.  Hence,  it  is  especially  important  to  have  techniques  for 
measuring  progress  toward  objectives,  and  for  analyzing  the  compromise 
between  them.  For  example,  consider  two  typical  objectives:  to  mini¬ 
mize  target  program  size(s),  and  to  minimize  target  program  execution 
time(t).  It  is  simple  enough  to  choose  between  two  optimization  tech¬ 
niques  if  the  difference  between  those  techniques  affects  only  s  or 
only  t,  but  this  is  rarely  the  case  in  light  of  potential  subsequent 
optimizations.  We  need  an  algorithm  to  trade  between  s  and  t.  Perhaps 
it  is  to  minimize  (s  *  t) ,  (As  +  t) ,  or  (s^  +  t"S .  The  algorithm  it¬ 
self  may  not  matter  as  much  as  the  fact  that  it  may  change  from  one 
segment  of  the  program  to  another  (e.g.,  local  minimization  of  t  has 
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more  affect  on  global  t  if  the  locale  is  in  a  loop).  If  we  define 
optimization  as  a  tendency  toward  less  comsumption  of  a  single  resource 
(or  fixed  proportion  of  several  resources),  then  we  c,an  optimize  only 
if  we  can  determine  the  consumption  of  that  single  resource.  In  fact, 
most  optimization  decisions  can  be  made  based  on  a  simple  resource 
(s,  or  t)  and  within  a  limited  context.  But  without  a  philosophy  for 
resource  definition  and  comparative  measure,  we  will  not  have  a  con¬ 
sistent  and  justifiable  approach  to  the  more  complex  optimizations. 

When  measuring  the  quality  of  a  compiler  some  attention  might  be 
given  to  the  cost  of  compilation.  The  compile-time  resources  that 
should  be  spent  for  a  given  improvement  in  object  program  quality  de¬ 
pend  on  the  intended  use  of  the  compiler.  For  the  compiler  writer  to 
determine  the  best  optimization  and  code  generation  strategies  to  apply, 
he  will  need  to  be  able  to  make  estimates  of  the  cost/benefit  ratios 
of  the  alternate  techniques. 

1 . 4  The  Retargetable  Compiler  Goals 

Much  of  theory  and  Dractice  of  compilation  and  compiler  generation 
has  been  developed  from  the  bottom  up.  That  is,  only  specific  problems 
have  been  addressed,  and  these  only  in  fairly  narrow  contexts.  This 
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is  not  to  discount  the  value  of  the  work  already  done.  We  would  like 
to  place  this  existing  knowledge  in  a  framework  of  needs  and  require¬ 
ments  that  is  derived  from  the  top  down.  This  would  clarify  the  gaps 
in  our  knowledge,  and  the  consequent  objective  of  closing  those  gaps. 
Additionally,  it  would  help  us  bring  some  sense  and  uniformity  to  this 
fragmented  field,  and  could  lead  to  a  philosophical  foundation  which 
is  necessary  for  rapid  progress. 

The  whole  field  of  automatic  compiler  generation  is  not  yet  mature, 
and  is  not  likely  to  become  so  for  some  time.  We  can,  however,  make 
use  of  what  we  do  know  provided  that  we  are  practical.  Toward  this 
end,  we  intend  to  concentrate  in  areas  of  theory  and  technology  which 
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appear  to  have  the  greater  pay-offs  in  features  that  are  desirable  in 
a  compiler  generator.  Those  areas  which  have  minimal  pay-off,  or  which 
cannot  be  implemented  without  a  great  expense  will  be  addressed  only 
in  regard  to  possible  future  work.  In  this  way,  we  will  provide  the 
basis  for  a  practical  retargetable  compiler  generator  which  exhibits 
good  balance  between  retargeting  effort  and  target  program  quality. 
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2.  SCOPE 


In  this  section  we  will  deal  with  those  constraints  which  we  feel 
realistically  limit  the  goals  of  the  retargetable  compiler,  and  there¬ 
by  define  the  goals  of  this  work. 

2 . 1  Languages  of  Interest 

The  programming  languages  for  which  retargetability  would  be  use¬ 
ful  are  legion,  and  more  are  developed  every  day.  Our  approach  to  op¬ 
timization  and  code  generation  issues  are  best  served  by  limiting  the 
languages  to  those  which  handle  the  data  structures  for  which  the 
general  purpose  machines  of  today  are  designed:  integer  and  real 
arithmetic,  and  composites  of  these.  Some  other  data  types,  which  are 
to  some  extent  machine  supported,  are  either  not  universal  enough  (e.g., 
decimal  arithmetic)  or  not  uniformly  treated  (e.g.,  byte  strings) 
across  the  range  of  computers  of  interest.  The  languages  included  are 
those  known  as  either  "algebraic"  languages,  or  "system  programming" 
languages,  and  include  FORTRAN,  BASIC,  ALGOL,  PASCAL,  BLISS,  and,  in 
particular  JOVIAL  and  Ada.  We  exclude  those  languages  which  require 
interpretation  or  extreme  run-time  library  support,  such  as  SNOBOL, 
LISP*and  APL.  These  languages  are  generally  characterized  by  their 
support  of  some  specific  data  structure  such  as  strings  or  lists. 

The  reasons  for  this  emphasis  on  languages  which  are  machine 
data-structure  supported  are  that  they  are  the  ones  for  which  extensive 
optimization  strategies  and  clever  code  generation  procedures  will  pro¬ 
vide  the  best  improvements  in  the  finished  object  code.  Those  languages 
which  are  heavily  run-time  supported  (in  order  to  handle  data  struc¬ 
tures  divorced  from  existing  machine  capabilities)  are  not  so  readily 
optimal  -  most  such  work  is  performed  in  writing  the  run-time  support 
package  for  each  machine. 
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Note,  however,  that  it  will  probably  be  impossible  to  build  any 
compiler  for  any  machine  without  some  kind  of  run-time  support  avail¬ 
able,  particularly  in  the  areas  of  input/output  processing,  storage 
allocation,  and  other  operating  system  interfaces. 

2 .2  Target  Machines 

The  choice  of  target  machine  for  the  retargetable  compiler  must 
likewise  be  limited.  We  must  (at  least  for  this  report)  discard  the 
special  purpose  machines  such  as  array  processors,  and  those  specialized 
for  high  level  languages,  such  as  pure  stack  machines.  We  will  not  be 
considering  machines  which  are  designed  to  specifically  implement  paral¬ 
lel  processes,  except  insofar  as  they  will  perform  as  a  single  proces¬ 
sor  on  the  target  code. 

Note  that  these  exclusions  do  not  seriously  limit  the  range  of 
general  purpose  processors  in  use  today.  We  do  plan  to  be  able  to 
generate  code  for  one  address(Intel  8080),  two  address  (PDP-11),  three 
address  (VAX)  and  general  register  architectures  (S/370,  1108)  as  well 
as  combinations  of  these  sets  (MODCOMP) .  This  will  include  most  of 
the  micro-processors  available  today,  as  well  as  most  minis  and  main¬ 
frames,  and  even  the  classes  of  micro-code  known  as  "vertical". 

The  primary  reasons  for  the  restrictions  on  the  machine  applica¬ 
bility  is  the  lack  of  unifying  compiler  theory  across  all  the  more 
special  purpose  machines.  The  somewhat  tenuous  existing  theory  of 
macnine- independent  optimization,  for  example,  does  not  at  all  address 
the  equivalent  problem  in  truly  parallel  processes. 

Finally,  the  retargetable  compiler  is  envisioned  to  be  just  that  - 
a  compiler  not  an  interpreter.  We  will  not  discuss  such  techniques  as 
run-time  monitoring  (in  the  sense  of  Knuth's  [Knu74luse  of  the  term) 
and  dynamic  optimization,  since  these  techniques  are  not  yet  practically 
useable.  They  are  indeed  subjects  for  future  research,  and  future  de¬ 
sign  of  the  Retargetable  Compiler  should  allow  for  the  possibilities  of 
such  techniques. 
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3.  THE  PROBLEM 


3. 1  Interpretation  of  the  SOW 

The  Statement  of  Work  [RFP]  for  the  Retargetable  Compiler  con¬ 
tract  is  broken  into  two  parts: 

investigation  of  ways  and  means  of  automatic  code  genera¬ 
tion,  and 

"detailed  recommendations  for  the  design"  of  a  retargetable 
compiler. 

The  first  section  contains  three  primary  areas  of  research: 

the  CDL  to  drive  the  code  generator  must  be  specified/ 
developed; 

a  complete  set  of  optimizations,  driven  by  the  CDL  descrip¬ 
tion,  must  be  specified;  and 

well  specified  intermediate  representation  must  be 
developed. 

The  last  section  of  the  SOW  specifies  that  the  design  must  include 
implementations  for  J73/1  and  Ada. 

We  will  present,  in  section  4.0  of  this  report,  both  our  design 

* 

and  the  algorithms  we  feel  fill  the  requirements  of  a  multi-machine 
environment.  In  this  section,  we  will  specifically  address  several  of 
the  issues  covered  by  our  research  into  Retargetable  Compiler  methods, 
and  address  the  J73/I  and  Ada  requirements  in  particular. 

The  SOW  assumes  that  compiler  front  end  technology  is  well  enough 
advanced  that  there  is  no  need  to  go  into  that  part  of  the  retargetable 
compiler.  As  far  as  the  research  portion  of  the  SOW  is  concerned,  this 
is  a  correct  assumption.  However,  we  feel  the  need  to  discuss  the 
front  end  processing  in  the  system  design  for  four  reasons: 
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The  requirement  that  we  specify  the  intermediate  language  (which 
is  input  to  code  generation  and  output  from  the  compiler  front- 
end)  infers  that  the  front-end  must  supply  said  language.  Unless 
we  choose  some  already  existing  front-end  and  its  intermediate 
language  or  equivalent,  then  we  must  at  least  hypothesize  a 
front-end  meeting  this  requirement. 

Some  opt imizat ions  of  the  machine-independent,  flow  analysis  type 
require  data  concerning  the  semantics  of  the  language  being 
translated,  the  generation  of  which  is  not  among  the  capabilities 
of  currently  existing  compiler-compilers.  This  will  be  considered 
in  more  detail  when  discussing  the  intermediate  language. 

The  final  paragraph  in  the  SOW  requires  the  design  to  be  appli¬ 
cable  to  (at  least)  two  different  languages.  This  requirement  is 
most  readily  compiled  with  by  designing  a  language  definition 
driven  compiler-compiler  front-end. 

Finally,  from  a  systems  engineering  point  of  view  it  is  best  to 
design  the  entire  system,  both  front-end  and  back-end,  together, 
in  order  to  avoid  interface  problems  and  promote  a  uniform  approach 
to  the  entire  retargetable  compiler  problem. 

With  these  points  in  mind,  we  will  treat  the  design  of  a  complete  com¬ 
piler-generator  rather  than  just  a  code-generator  generator. 

3.2  Research  Topics 

There  are  five  primary  areas  of  research  connected  with  the  retarget¬ 
able  compiler: 

-  computer  description  languages; 
intermediate  languages; 
machine  independent  optimization; 
code  generation  techniques; 
machine  dependent  optimizations. 
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3.2.1  Computer  Description  Languages 


Current  code  generation  techniques  are  oriented  toward  an  instruction 
set  processor.  Code  generation  is  seen  as  a  process  of  producing  machine 
language  instructions  which  are  interpreted  by  some  target  machine.  This 
interpretation  cycle  assumes  the  execution  of  one  instruction  at  a  time,  with 
the  instructions  being  retrieved  from  an  instruction  memory,  and  with  the 
ability  to  make  the  sequence  of  execution  dependent  on  data  values.  Addi¬ 
tionally,  current  code  generation  techniques  assume  a  main  data  memory  and 
can  exploit  such  common  features  as  high-speed  registers,  condition  codes, 
and  multi-action  instructions.  Instructions  are  assumed  to  be  defined  strictly 
in  terms  of  the  values  read  from  and  written  into  memories.  These  memories 
include  main  memory,  registers,  the  program  counter,  and  condition  codes. 


These  characteristics  of  current  code  generation  techniques  point  to 
various  traits  in  a  CDL  that  would  be  helpful  for  generating  code  for  a  ma¬ 
chine  described  in  that  CDL.  First,  since  code  generation  techniques  assume 
an  interpretation  cycle,  with  the  variability  between  machines  being  in  the 
individual  instructions,  the  description  language  should  focus  on  the  behavior 
of  these  individual  instructions,  providing  tools  for  exact  description  of 
their  behavior.  The  instruction  descriptions  should  be  high  level,  simply 
describing  the  mappings  from  the  inputs  to  the  outputs  of  the  instructions. 

The  description  language  should  require  the  presence  of  exactly  one  program 
memory  and  exactly  one,  clearly  identified  program  counter.  Also  needed  are 
tools  for  the  description  of  the  various  memories  of  the  machine.  To  allow 
the  code  generator  tc  make  optimization  choices,  the  description  must  give 
the  costs  in  time  and  memory  space  of  the  instructions.  In  addition  to  these 
content  requirements  for  the  description  languages,  it  is  also  desirable  that 
the  language  be  easy  to  use  and  of  wide  applicability  so  that  machine  descrip¬ 
tions  may  be  already  available  from  other  applications  or  easy  to  write  if 
no  existing  description  exists  for  a  machine  of  interest. 


We  have  examined  fourteen  languages  in  use  today  which 
hardware  to  some  extent.  (See  Appendix  A)  These  are: 


describe  digital 
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ISP  and  derivatives  (ISP  ,  ISPS) 
CDL  and  Purdue  Extended  CDL 


LALSD 


SMITE 


CASS ANDRE 


LOGAL 


ConLan 


(Instruction  Set  Processor) 

(Computer  Description  Language) 

(Digital  Design  Language) 

(A  Language  for  Automated  Logic 
and  System  Design) 

(j5oftware  Machine's  Implementation 
Tool  using  Emulation) 

(A  Hardware  Programming  Language) 

(A  Programming  language) 

(Machine  Operations) 

(Algorithmic  Processor  Description 
Language) 

(Logic  Algorithm  Language) 

(Language  for  Computer  Design) 

(jJrlanger  Rechner-Entwurf s-Sprache- 
Erlangen  Computer  Description  Language) 
(Consensus  Language) 


MOP,  developed  by  Cattell  at  CMU,  is  an  obvious  candidate  based  on  these 
criteria.  It  was  developed  for  code  generation  with  the  above  criteria  in 
mind.  It  assumes  an  interpretation  cycle,  which  is  not  made  explicit  in  the 
description,  which  executes  instructions  stored  in  a  main  memory.  In  fact, 
no  overall  control  structure  or  algorithm  is  given  for  the  machine,  with  con¬ 
trol  being  left  to  the  assumed  interpretation  cycle.  The  main  memory  is  also 
used  to  store  data.  Each  instruction  is  identified  and  described  separately, 
with  the  description  giving  the  fields  of  the  instruction,  its  operation  code, 
its  costs,  and  its  actions.  The  actions  are  described  in  terms  of  the  input 
and  output  of  the  instruction.  Tools  are  provided  for  the  exact  and  clear 
description  of  available  memories  and  how  they  are  accessed  by  the  various 
instructions.  Clarity  of  the  description  here  includes  the  capacity  for 
automated  analysis.  Memories  are  described  in  terms  of  width,  length,  and 
function.  Also  given  are  the  instruction  fields  and  field  values  needed 
to  use  the  various  access  modes  for  the  various  memories.  At  the  same  time, 
MOP  is  easy  to  use,  so  machine  descriptions  may  be  easily  prepared. 


Wide  applicability  of  a  CDL  is  in  conflict  ^ith  the  rest  of  the  above 
criteria,  and  as  is  almost  inevitable,  MOP  is  too  specialized  for  wide  appli¬ 
cability.  Particularly,  its  assumption  of  an  interpretation  cycle  and  high 
level  of  description  make  it  unsuitable  for  many  applications.  However,  ISPS, 
a  very  general  and  widely  used  language  can  be  translated  into  MOP  in  an  al¬ 
most  completely  automatic  manner  [Oak79].  ISPS  is  a  derivative  of  ISP  and 
is  an  easy  to  use  language  that  can  be  used  at  many  levels  of  detail  and  pro¬ 
vides  very  powerful  modularization  constructs  which  are  useful  for  both 
writing  and  analyzing  descriptions.  The  data  types,  accessing  mechanisms, 
and  operators  provided  by  ISPS  closely  correspond  to  those  existing  in  cur¬ 
rent  computers.  These  close  correspondences  make  descriptions  easy  to  write 
and  facilitate  the  writing  of  accurate  descriptions.  The  simple  control 
constructs  in  ISPS  are  easy  to  analyze  and  closely  correspond  to  those  avail¬ 
able  in  computer  hardware.  ISPS  has  some  powerful  extension  mechanisms  that 
have  made  it  suitable  for  describing  a  large  number  of  computers  for  a  wide 
range  of  applications,  including  a  great  deal  of  work  at  CMU. 

It  should  be  noted  that  the  work  necessary  to  produce  MOP  from  ISPS 
(symbolic  execution,  I/O  assertion  development,  etc.)  does  not  duplicate 
much  of  the  work  in  using  MOP  for  code  generation,  and  thus  the  use  of  MOP 
as  the  immediate  input  to  code  generation  does  not  introduce  extra  work, 
even  when  the  only  available  description  of  a  computer  is  in  ISPS.  Also, 
if  no  ISPS  or  MOP  description  of  a  machine  is  available,  a  MOP  description 
may  be  written  by  hand  comparatively  quickly  and  easily. 

3.2.2  Intermediate  Languages 

The  Intermediate  language  is  the  language  used  to  represent  user's  pro¬ 
gram  between  passes  of  the  compiler.  In  particular,  it  is  the  form  between 
the  syntactical/semantic  encoding  and  the  code  generation  phases,  and  there¬ 
fore  at  the  state  where  most  (not  all!)  of  the  language  dependent  features 
are  absent,  and  before  any  machine  dependencies  have  occurred  [CAT78 ,HW78 J . 
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Intermediate  languages  (IL)  originally  were  designed  to  effectively 
carry  information  between  passes  of  a  compiler  with  little  thought  given  to 
making  them  general.  It  was  soon  realized  that  if  a  suitable  IL  could  be 
developed,  then  interchangeable  front  ends  and  back  ends  would  reduce  the 
work  of  producing  compilers  for  n  machines  and  m  languages  from  producing 
m  x  n  compilers  to  m  plus  n  compilers,  a  significant  reduction  in  effort 
[ Col74  ] . 

With  this  in  mind,  ILs  were  designed  for  their  own  sake,  and  the  ideas 
of  language/machine  independence  were  first  explored.  The  first  such  IL  was 
developed  by  Mock  and  Steel  [MOS58]  and  called  UNCOL.  Later  efforts  along 
the  same  line  include  Coleman  and  Wait's  JANUS  [Col74,  WH78]  and  Cattell's 
TCOL  family  of  ILs  [ Cat78,  SLN79 ] . 

Several  ILs  are  rather  language  dependent,  but  have  come  to  prominence 
because  of  unique  features  or  special  implementation  solutions.  These  in¬ 
clude  HALMAT  (for  HAL  compilers)  [1174],  the  JOCIT  IL  (for  J0VIAL/J3)  [Dun75] 
and  OCODE  (for  BCPL)  l  Ric 711.  An  extended  consideration  of  each  above  named 
IL  (except  UNCOL)  is  given  in  Appendix  B. 

Because  of  their  language  independence,  JANUS  and  TCOL  are  the  only 
ILs  from  Appendix  B  that  will  be  considered  as  the  IL  for  the  Retargetable 
Compiler. 

JANUS  was  designed  as  a  universal  IL.  It  provides  a  large  set  of  opera¬ 
tors  and  a  Flexible  storage  scheme.  Its  control  and  data  structures  are  at 
a  fairly  low  level,  and  it  uses  a  stack  for  intermediate  results.  It  is  a 
linear  language  that  does  not  depend  on  a  symbol  table  and  was  designed  to 
be  translated  by  a  macro  processor. 

TCOL  was  designed  by  Cattell  as  a  universal  IL  for  use  with  the  MMM 
algorithm.  TCOL  is  a  class  of  languages,  and  TCOL  is  a  particular  member 
developed  at  Carnegie-Me 1  Ion  University.  TCOL  programs  are  trees,  with 
fairly  high  level  data  and  control  constructs. 


TCOL  and  JANUS  Comparison 


The  machine  independence  and  extendability  of  the  two  languages  are 

practically  equivalent.  Although  the  language  independence  of  TCOL, .  is 

Ada 

less  than  that  of  JANUS,  as  mentioned  in  the  appendix  this  will  not  be  a 
practical  obstacle,  since  the  compiler-compiler  will  reduce  the  effort 
needed  to  adapt  to  changes  in  the  IL.  The  considerations  left  are  the  level, 
temporary  storage  and  suitability  for  code  generation  of  the  two  languages. 
The  first  two  qualities  are  important  because  they  affect  the  suitability 
of  the  languages  for  code  generation. 

JANUS  is  a  language  that  is  very  language  independent,  fairly  low-level 
and  with  fairly  simple  data  types.  These  qualities,  and  its  stack,  mechanisms 
were  motivated  by  the  design  goal  that  it  be  suitable  for  translation  to 
machine  code  by  a  macro  translator.  TCOL  on  the  other  hand,  has  high  level 
control  constructs,  with  high  level  data  types  and  no  explicit  stack.  This 
structure  is  motivated  by  the  desire  to  make  the  IL  program  easily  manipulat- 
able  by  optimizers,  code  generators,  etc.  but  it  makes  the  translation  to 
machine  code  more  difficult. 

Botli  JANUS  and  TCOL  are  suitable  for  the  optimizations  and  code  gen¬ 
eration  techniques  described  in  this  report.  TCOL's  higher  level  makes  opti¬ 
mizations  easier,  however,  and  its  tree  structure  is  conceptually  well 

suited  to  tree-matching  code  generation  techniques.  TCOL  is  therefore 

Ada 

our  choice  for  the  Retargetable  Compiler  IL. 

3.2.3  Mac hine  Independent  Optimizations 

The  theory  of  machine  independent  optimizations,  as  stated  before, 
has  been  fairly  well  explored  and  a  good  basis  for  use  has  been  advanced 
to  practicality,  notably  with  the  BLISS11  compiler  rWJW751. 

Conceptually  these  optimizations  can  be  reduced  to  three  classes  of 
operations:  code  movement,  constant  folding,  and  dead  code  elimination. 

The  first  can  be  subdivided  into  the  several  situations  in  which  moving  code 
(and  subsequent  consolidation)  may  provide  greater  efficiencies.  We  will 
mention  each  in  turn  below. 
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Constant  folding  -  this  optimization  results  from  the  appearance  of 
expressions  involving  only  constants  in  the  program  tree.  These  expressions 
could  have  resulted  from  a  programmer's  explicit  expression  (PI=3 . 14 159 ; PI 2= 
2.*PI)  or  implicitly,  such  as  in  subscript  evaluation  (REAL  A(5,2);  ... 
B=A(2,I)).  The  ability  to  do  constant  folding  can  happen  at  any  time  from 
first  tree  build  through  all  the  other  code  movement  optimizations,  as  re¬ 
construction  juxtaposes  constants  that  were  previously  separated. 

Dead  code  elimination  -  some  of  the  optimizations  discussed  below, 
particularly  variable  and  constant  propagation,  sometimes  result  in  code 
which  will  not  be  executed  under  any  circumstances .  This  dead  code  can  be 
detected  and  eliminated. 

Both  constant  folding  and  dead  code  elimination  always  should  be  effec¬ 
ted  as  soon  as  the  proper  conditions  are  detected,  inasmuch  as  they  always 
result  in  a  smaller,  more  efficient  program  tree.  The  remaining  methods, 
classed  as  code  movements,  do  not  always  increase  the  efficiency  for  all 
desirable  measures  of  efficiency.  Therefore,  code  movements  should  only  be 
performed  after  the  cases  can  be  measured  and  compared  in  a  meaningful  way. 

Redundant  expression  elimination  -  this  is  the  case  of  a  value  being 
calculated  more  than  once  in  a  code  block.  Generally,  the  result  of  the 
first  calculation  may  be  saved  and  used  in  place  of  the  second  calculation. 
This  kind  of  optimization  appears  most  frequently  as  the  result  of  subscript 
computations. 

Hoisting  code  motion  -  when  a  . ilue  is  identically  computed  in  each 
branch  from  a  flow  path,  that  computation  may  be  hoisted  into  the  common 
path  and  eliminated  in  the  branches.  The  same  idea  allows  common  statements 
made  in  branches  to  be  dropped  below  the  point  where  they  flow  together. 

Rho  motion  [LCH79]  -This  optimization  attempts  to  assure  that  a  compu¬ 
tation  is  performed  only  once  in  a  given  flow  instance.  For  example: 


Figure  3.2  Rho  Motion  Optimization 


This  motion  may  not  seem  useful  unless  the  common  path  is  part  of  a  loop. 

In  the  trivial  case,  this  is  known  as  moving  invariant  code  out  of  loops. 

Strength  reduction  -  This  optimization  attempts  to  eliminate  expensive 
operations  through  use  of  less  expensive  ones.  This  is  particularly  useful 
for  indexing  inside  loops  where  an  implicit  multiplication  of  a  subscript 
can  be  avoided  through  saving  and  later  adding  to  the  previously  calculated 
displacement  if  the  subscript  is  being  increased  by  a  constant  each  time 
around  the  loop. 


3.2.4  Code  Generation  Techniques 


The  direct  final  translation  into  machine  or  assembly  language  for  the 
target  machine  is  code  generation.  There  are  several  fairly  well  defined 
ways  of  producing  this  effect: 

ad  hoc  code  generation 
-  macroprocessing 

code  generator  languages 

machine  description  -  driven  techniques 

Most  of  the  code  generators  behind  today's  compilers  are  written  using 
ad  hoc  techniques,  which  means  that  code  to  handle  each  construct  of  its 
input  i..  hand  written  as  a  special  case  on  any  particular  machine.  This  is 
the  brute  force  method,  applied  in  the  absence  of  any  coherent  theory 
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covering  code  generation.  In  order  to  convert  the  code  generator  for  any 
other  machine,  a  complete  rewrite  is  required,  with  almost  al]  of  the  orig¬ 
inal  effort  being  unuseable.  The  efficiency  of  the  code  produced  is  in 
direct  proportion  to  the  effort  expended,  as  Wulf  has  demonstrated  with  the 
BLISS  11  compiler. 

Macroprocessing  is  a  generalization  of  the  text  processing  mechanisms 
found  in  many  assemblers  in  which  user  generated  "macros"  direct  the  trans¬ 
lation  of  text  [CHM78].  They  have  been  used  extensively  to  provide  exten¬ 
sions  onto  many  high  order  languages,  and  may  likewise  translate  some  flat¬ 
tened  intermediate  structure  into  assembly  source  text.  The  power  in  the 
method  is  in  direct  proportion  to  the  power  of  the  macroprocessor  used. 

Some  processors  are  quite  simple  and  easy  to  use;  the  cost  is  loss  of  flexi¬ 
bility.  The  more  powerful  processors  allow  flexibility  rivalling  assembly 
languages  themselves,  at  the  cost  of  difficulty  in  preparing  the  macros.  In 
the  extreme,  writing  the  macros  becomes  equivalent  to  writing  the  code 
generator  itself. 

The  macroprocessor  approach  fails  because  the  tool  itself  is  too  gen¬ 
eral  -  it  cannot  take  advantage  of  the  reduced  functional  requirements  that 
the  restricted  goal,  code  generation  affords.  This  weakness  in  approach 
is  covered  by  the  code  generator  languages  rDNF79!.  They  are,  in  effect, 
special  purpose  languages  designed  for  building  code  generators,  and  thus 
provide  the  code  generation  flavor  missing  from  the  macroprocessors.  Code 
generators  become  much  easier  to  write  than  in  the  ad  hoc  method,  but  each 
one  still  must  be  written  separately.  Again,  the  quality  of  the  code  gen¬ 
erated  reflects  the  skill  and  effort  expended  in  writing  the  code  generator. 

The  final  method  of  code  generation,  using  a  machine  description,  breaks 
from  the  previous  techniques  in  that  the  machine  dependent  parts  of  the  code 
generator  are  reduced  to  tables,  and  are  generated  automatically,  based  on  a 
machine  description  [Cat78j,  [Fra77^,  fGla73l.  It  is  true  that  the  descrip¬ 
tion  must  be  supplied  for  each  machine,  but  that  seems  to  be  a  lesser  effort 
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than  hand  writing  the  code  generator,  and  besides,  the  same  description  may 
be  used  in  several  other  ways  in  the  compiler  and  related  projects,  such 
as  hardware  design  verification,  diagnostics  generation,  etc.,  and  thus  the 
effort  is  "amortized"  across  a  series  of  uses.  Moreover,  the  machine  de¬ 
scriptions  for  a  number  of  machines  already  exist  and  could  conceivably  be. 
used  as  is. 

With  all  these  considerations  in  mind,  it  seems  that  the  machine  de¬ 
scription-driven  methods  of  code  generation  are  most  appropriate  for  the 
Retargetable  Compiler. 

3.2.5  Machine  Dependent  Optimizations 

This  class  of  optimizations  is  not  appropriately  named,  since  several 
of  the  optimizations  discussed  here  are  largely  machine  independent. 

The  single  common  characteristic  of  these  optimization  techniques  is 
that  they  can  best  be  performed  only  after  code  generation  is  finished.  Some 
need  to  know  actual  code  sizing;  some  are  code  to  code  replacements  (or 
straight  eliminations)  for  particular  code  sequences. 

The  utter  lack  of  theoretical  basis  for  tying  these  optimizations  to¬ 
gether  requires  that  they  be  treated  as  totally  separate  items.  All  are 
machine  dependent  in  the  sense  that  they  need  to  know,  for  instance,  what 
a  branch  instruction  looks  like,  but  some  need  no  more  than  that,  whereas 
some  need  much  more  data  concerning  the  target  machine. 

Many  such  operations  are  available  in  the  literature.  Some  of  the  bet¬ 
ter  known  and  more  general  ones  are: 

cross  jumping  -  elimination  of  code  on  two  merging  paths  which  is 
identical . 

unreachable  code  -  detection  and  elimination  of  code  between  an  uncondi¬ 


tional  branch  and  the  next  label. 


Branch  chain  elimination  -  if  a  branch  instruction  addresses  an  uncon¬ 
ditional  branch,  make  it  a  direct  branch  to  the  sfecond  target. 

Redundant  code  elimination  -  elimination  of  instructions  that  are  effec¬ 
tive  NOPs  to  the  target  machine. 

Reversing  branch  sense  -  if  a  conditional  branch  is  followed  by  an  un¬ 
conditional  branch,  and  then  the  target  of  the  first,  the  sense  of  the  con¬ 
dition  may  be  changed  to  eliminate  the  second  branch. 

Superfluous  compare  -  delete  compare  instructions  when  previous  opera¬ 
tions  have  already  set  the  condition  codes. 

Special  case  literal  operands  -  delete  instructions  such  as  OR  with 
literal  0,  etc. 

Auto  increment  modes  -  some  machines  can  automatically  increment  or 
decrement  pointers.  Use  of  these  can  eliminate  explicit  incrementation. 

Reduction  to  simpler  form  -  some  instructions  can  be  reduced  in  size 
Jo  an  equivalent  form,  such  as: 

ADD  #4,SP  ^  CMP  (SP)+,(SP)+ 
on  the  PDP  1 1 . 

Short  form  length-dependent  instructions  -  some  machines  have  short 
form  instructions  for  use  when  the  target  operand  is  some  small  relative 
distance  from  the  instruction.  The  algorithm  to  reduce  these  is  non-trivial 
and  requires  a  fair  amount  of  analysis  TSzy78]. 

These  optimizations  are  only  examples.  No  doubt  new  architectures  will 
open  new  opportunities  for  novel  methods  of  peephole  optimization. 
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3. 3  The  J73/I  and  Ada  Requirement 

JOVIAL  and  Ada  are  both  outgrowths  of  the  ALGOL  language.  JOVIAL  in¬ 
itially  added  byte  and  bit  level  constructs  in  order  to  expand  ALGOL  into 
a  systems  programming  language,  while  Ada  has  been  developed  from  PASCAL  in 
order  to  provide  PASCAL'S  data  abstraction  and  modern  program  structuring 
to  a  language  suited  for  use  in  embedded  computers. 

Both  languages  fall  within  the  language  bounds  listed  in  the  scope 
section  of  this  report.  Both  are  block  oriented,  procedural,  algebraic  lan¬ 
guages,  and  both  are  syntacticly  describable  by  LALR(l)  grammars.  They 
therefore  will  both  be  amenable  to  analysis  by  our  automatically  generated 
syntax  analysis  (see  the  next  section).  They  will  thus  generate  language 
independent  intermediate  code,  suitable  for  code  generator  input. 
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4.  A  SOLUTION  DESIGN 


Using  the  studies  made  in  the  last  section  and  our  own  study  of  the 
state  of  the  art,  we  shall  propose  in  this  section  a  conceptual  design  for 
a  retargetable  compiler. 

We  will  describe  in  general  terms  both  the  compiler  generator  and  the 
compiler  architecture  itself.  This  is  followed  by  more  detailed  discussions 
of  each  module  in  the  back-end  of  the  compiler,  which  is  the  area  of  pri¬ 
mary  interest  to  this  report. 

Finally,  we  have  attached  a  more  detailed  description  of  our  primary 
descriptive  input,  the  MOP.  We  have  included  this  so  that  the  reader  may 
more  readily  see  the  kind  of  description  it  is,  and  the  data  it  contains. 

4 . 1  Compiler  Generator  Architecture 

Input  to  the  generator  will  be  in  two  sections,  a  machine  description 
and  a  language  description.  The  code  for  most  phases  of  the  generated  com¬ 
pilation  system  will  be  invariant,  with  language  and  machine  dependences 
described  in  data  supplied  by  the  generator.  Lexical  analysis  may  require 
a  description  of  the  language's  lexical  structure.  Syntax  analysis  will 
require  a  parse  table  which  includes  descriptions  of  connection  point  calls. 
Semantics  routines  may  require  various  information  about  the  language,  com¬ 
pilation  machine  and  target  machine. 

Flow  analysis  will  require  information  about  compilation  machine  data 
types  for  use  in  constant  folding.  It  will  also  require  a  description  of 
possible  transformations.  Code  generation  will  need  descriptions  of  the 
target  instructions  to  implement  each  IL  construct  and  a  description  of  the 
data  types  and  access  modes  of  the  target  machines.  Memory  allocation  will 
require  a  description  of  the  physical  data  types  and  access  modes  of  the 
target  machine. 
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To  produce  this  information  from  its  input,  the  generator  will  need  to 
do  several  kinds  of  processing.  It  must  use  standard  parser  generation 
techniques  to  produce  the  needed  parse  tables.  A  simpler  extraction  may  be 
appropriate  to  give  lexical  analysis  the  information  it  needs.  Cattell 
has  described  techniques  for  extracting  the  tables  code  generation  needs. 
Simpler  analysis  and  extraction  are  needed  to  get  the  information  flow  an¬ 
alysis  and  memory  allocation  need  from  the  machine  description. 

This  leads  to  identifiable  functions  for  the  generator  which  can  be 
isolated  in  modules.  A  description  of  the  lexical  structure  may  need  to  be 
extracted  from  the  language  description.  Parse  tables  must  also  be  genera¬ 
ted  for  syntax  analysis  from  the  language  description.  Descriptions  of  the 
target  and  compilation  machine  types  may  be  needed  by  the  two  code  genera¬ 
tion  modules,  ORD  and  CG  will  need  possibly  distinct  semantics  and  flow 
analyses  descriptions  of  the  target  realizations  of  TCOL  constructs  along 
with  their  costs. 

A  description  of  the  storage  bases,  data  types,  and  access  modes  must 
be  extracted  from  the  machine  description  for  memory  allocation. 

4 . 2  Compiler  Architecture 

For  reliability  and  simplicity,  it  is  desirable  that  as  much  as  possi¬ 
ble  of  the  retarget  compiler  be  invariant,  written  once  for  all  language- 
machine  pairs.  A  great  deal  of  research  has  gone  into  identifying  the  lan¬ 
guage-  and  machine-dependent  aspects  of  syntactic  analysis,  flow  analysis, 
code  generation  and  resource  allocation.  The  retargetable  compiler  system 
will  exploit  this  work  by  isolating  the  machine  and  language  dependencies 
of  the  above  processing  in  data  tables,  rather  than  attempting  to  synthesize 
appropriate  code. 

The  structure  of  the  retargeted  compiler  will  be  somewhat  similar  to 
that  of  the  BLISS11  compiler  described  in  'WJW751.  It  is  pictured  in 
Figure  4.1. 
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Lexical  analysis,  syntactic  analysis,  semantic  analysis  and  production 
of  the  IL  form  of  the  program  will  be  handled  in  a  single  conceptual  pass. 
These  functions  are  handled  by  the  phases  LEX,  SYN,  SEM  and  TRL  respectively. 
Flow  analysis,  evaluation  order  determination,  storage  allocation,  code 
generation  and  "peephole"  optimization  will  each  be  handled  by  a  single 
phase  in  a  pass  by  itself,  named  FLO,  ORD,  TNB,  CG  and  FOP,  respectively. 

To  make  LEX  invariant  over  all  languages  would  seem  overly  ambitious, 
because  of  efficiency,  the  difficulty  of  formally  describing  a  lexical  syn¬ 
tax  and  the  dependence  of  lexical  interpretation  on  context.  Fortran  and 
PL/I  can  be  particularly  tricky  in  their  lexical  structure.  In  addition, 

LEX  will  need  to  build  the  tokens  which  are  used  by  the  SEM  routines,  which 
are  supplied  by  the  implementor,  so  for  LEX. to  be  invariant,  it  must  build 
tokens  that  supply  all  the  information  that  any  SEM  routines  might  need. 

This  seems  hopeless  and  unproductive.  However,  for  a  class  of  languages 
with  regular  lexical  structure  these  arguments  no  longer  apply  and  the  ad¬ 
vantages  of  using  proven  routines  and  a  formal  description  system  become 
more  compelling.  A  middle  ground  is  to  have  invariant  scanners  to  collect 
strings  of  digits,  and  letters  and  skip  comments  and  blanks.  The  implementor 
can  then  write  a  screener  that  uses  these  primitives  to  ease  his  coding  task. 
Also,  one  can  supply  a  variety  of  packages  appropriate  to  specific  languages 
or  classes  of  languages.  The  choice  of  lexical  analysis  strategies  is  thus 
dependent  on  the  class  of  languages  one  wishes  to  address  and  other  design 
goals.  Only  in  one  way  will  LEX  differ  from  traditional  lexical  analyzers: 
LEX  will  not  resolve  constants  which  occur  in  the  program.  Instead,  they 
will  be  stored  in  a  string  table  just  as  they  occur  in  the  program  and  will 
be  converted  as  required  (in  FLO  and  CF  for  the  compiler  computer,  in  CG 
for  the  target). 

SYN  will  be  based  on  syntax-directed  parsing  techniques.  An  LALR(l) 
or  LL(1)  parser  generator  embedded  in  the  generator  can  generate  the  needed 
parse  tables.  SYN  can  exploit  automatic  error  recovery  techniques  though 
it  is  probably  best  to  avoid  techniques  that  modify  the  syntactic  stack, 
since  this  will  avoid  inconsistent  calls  on  the  semantic  routines  simplify¬ 
ing  the  implementor's  task  in  writing  these  routines.  Since  SYN  will  only 
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be  written  once,  it  is  preferred  that  it  be  implemented  in  a  way  that  eases 
the  writing  of  more  variable  parts  of  the  compiler,  even  if  SYN's  complexity 
is  thereby  increased. 


SEM  will  be  a  collection  of  routines  supplied  by  the  implementor  to 
do  the  semantic  analysis  of  the  source  program.  The  routines  are  envoked 
by  SYN  as  directed  by  the  parse  tables,  and  will  determine  possessions, 
check  compatibilities,  perform  operator  identification  and  attribute  coordi¬ 
nation,  and  call  upon  TRL  routines  to  build  the  IL  program  tree.  SEM  will 
encode  in  the  tree  source  and  target  data  types  and  accessing  information 
for  the  operands  in  the  tree.  To  support  optimization,  SEM  will  also  need 
to  encode  the  logical  orderings  required  by  the  source  language,  as  speci¬ 
fied  in  the  discussion  of  FLO.  Attribute  grammars  have  been  proposed  as  a 
way  of  formally  describing  the  semantics  of  a  language  and  directing  the 
semantic  analysis  of  a  program,  but  this  technology  does  not  yet  seem  well 
enough  understood  or  efficient  enough  for  use  in  a  practical  compiler. 

The  TRL  routines  will  be  invariant  and  will  include  generalized  symbol 
table  and  IL  construction  routines.  The  symbol  table  routines  will  need  to 
support  the  processing  needs  for  languages  with  controlled  scope  (e.g.,  Ada, 
Euclid),  explicit  aliasing  (Fortran),  user  defined  modes,  and  other  features 
of  existing  languages.  The  IL  construction  will  need  to  support  the  speci¬ 
fication  of  required  orderings,  source  data  types  and  target  data  types  men¬ 
tioned  above.  The  implementor's  coding  burden  will  be  greatly  eased  by 
these  routines  and  they  will  protect  the  integrity  of  the  symbol  table  and 
IL. 


For  some  languages,  such  as  Pascal  and  Fortran  ,  LEX,  SYN,  SEM,  and 
TRS  could  operate  in  parallel  as  part  of  the  same  pass,  with  analysis  of 
the  program  and  production  of  IL  proceeding  together.  For  other  languages, 
such  as  Ada,  multiple  analysis  passes  may  be  required  and  production  of  IL 
must  be  postponed  to  the  final  analysis  pass.  These  passes  will  be  imple¬ 
mented  by  SEM,  leaving  SYN  and  TRL  unchanged.  + 
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FLO  will  perform  global  analysis,  doing  live/dead  analysis  on  variables, 
constant  propogation  and  folding,  identifying  dead  code,  dead  variables, 
common  subexpressions,  and  finding  opportunities  for  code  motion  and  strength 
reduction.  It  will  make  use  of  ordering  information  in  the  IL.  FLO  will 
use  the  same  IL  format  as  input  and  output,  with  its  functions  only  being 
IL  transformations,  leaving  FLO  invariant  from  compiler  to  compiler. 

ORD  will  make  decisions  about  potential  optimizations  identified  by 
FLO,  determine  evaluation  order  and  identify  temporary  names  (temporary 
results),  specifying  their  lifetimes,  preferred  target  data  type,  storage 
base  and  access  mode. 

Cattell  has  described  a  method  discussed  below  and  in  r Cat78]called 
MMM,  and  a  data  structure,  the  LOP,  useful  for  approaching  this  problem. 

ORD  will  output  a  modified  IL  tree  and  a  description  of  required  temporary 
names.  TNB  will  assign  target  memories  to  the  various  temporary  names  de¬ 
scribed  by  ORD.  Where  possible,  TNB  will  assign  multiple  temporary  names 
to  a  single  memory. 

CG  will  use  the  memory  assignments  calculated  bv  TNB  to  implement  the 
IL  program  produced  by  ORD.  Again,  the  MMM  and  LOP  described  by  Cattell 
will  be  useful.  In  addition,  a  temporary  storage  manager  will  be  required 
by  CG  where  assignments  by  TNB  make  the  evaluation  order  specified  by  ORD 
impossible.  The  temporary  manager  would  save  the  values  in  currently  allo¬ 
cated  but  required  memories  and  then  restore  the  old  values  later,  much  in 
the  manner  of  conventional  register  allocators. 

FOP  will  perform  "peephole"  optimizations  using  as  its  target  machine 
code  input  and  output,  correcting  inefficiencies  in  CG's  output  due  to  code 
from  widely  separated  parts  of  the  IL  tree  becoming  adjacent  in  the  produced 
machine  code.  These  optimizations  include  elimination  of  redundant  machine 
operations  such  as  loops,  loads  and  stores,  and  branches  to  branches.  These 
transformations  are  really  hard  to  systemize  and  will  be  supplied  by  the 
implementor . 
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In  the  remainder  of  this  section  we  will  concentrate  on  the  algorithms 
and  peculiarities  of  the  "backend"  routines,  namely  CF,  FLO,  ORD,  TNB,  CG , 
and  FOP.  These  routines  are  of  the  primary  interest  to  retargetable  com¬ 
piler  study,  since,  as  noted  in  the  SOW  and  the  introduction  front-end 
theory  and  practice  are  well  established. 


Module  Generator: 


Input 


Processor 


Output 


syntax  grammar  of 
language 


LALR(l)  compiler-compiler 
(e.g.,  YACC) 


LALR(l)  syntax 
tables 


source  program 


Compiler  Module: 

-  LAL.R(l)  parser  with 

tab les 

-  user  supplied  lexical 

analyzer 

-  user  supplied  semantics 

routines 

-  TRL  tree  and  table  mani¬ 

pulation  routines 


-  TOOL  program  tree 

-  svmbol  table 

(including 
string  and 
constant  tables) 


Figure  4.2  LEX/SYN/SEM/TRL  HIPO  Chart 
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-  Symbol  table  decision  routines 

-  FLO  processor 
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Figure  4.3  FLO  HIPO  Chart 


-  TCOL  program  tree 
with  constants 
folded,  unused 
code  eliminated, 
common  subexpres¬ 
sions  threaded, 
and  code  motions 
ident i f ied 


4.3.1  FLO  -  Flow  analysis 


The  FLO  module  performs  data  flow  analysis  on  the  program  tree,  performs 
constant  propagation  and  detects  other  possible  FLO  and  classical  optimiza¬ 
tions.  The  difference  between  FLO  and  classical  optimizers  is  that  FLO  de¬ 
tects  possible  global  optimizations,  but  the  desirability  of  performing  a 
given  transformation  is  determined  later,  by  ORD.  This  is  the  technique 
used  by  Wulf  et  al.  in  the  BLISSli  compiler. 

A  global  optimizer  needs  to  determine  the  lifetime  of  each  variable  or 
computation  (data  I  low  analysis),  and  to  determine  feasible  optimizations, 
which  are  motions  ir  eliminations  of  computations  in  the  program.  Most  of 
thi'  work  performed  by  the  optimizer  is  language  independent.  Language  de¬ 
pendencies  arise  in  two  ways:  limitations  on  the  lifetime  of  a  variable 

and  limitations  on  when  rode  motion  is  legal  given  t he  semantics  ot  the 
source  language.  To  move  or  eliminate  computations,  the  optimizer  must 
determine  t  lie i r  liletimes,  and  whether  or  not  relationships  between  objects 


can  be  changed  in  a  given  situation.  As  an  example  of  the  effect  of  lan¬ 
guage  semantics  on  lifetimes,  a  function  call  in  Fortran  may  alter  any 
variable  in  COMMON.  As  an  example  of  the  effect  of  semantics  on  possible 
optimization  is  that  in  Fortran  association  and  commutation  may  always  be 
applied  to  multiplication;  in  Algol  this  is  not  true.  These  effects  have 
to  be  taken  into  account  in  the  optimizer  for  a  given  language,  and  in  FLO 
user-provided  procedures  will  do  this.  There  are  a  number  of  formulations 
of  global  analysis  in  the  literature,  some  quite  recent.  The  one  that  will 
be  used  in  this  discussion  is  the  one  developed  by  Geschke  Ges72l  in  his 
thesis  and  used  in  the  BLISS  11  compiler.  Its  advantage  is  that  it  makes 
the  isolation  of  language  dependent  information  simple. 

According  to  Geschke,  the  language  dependencies  of  FLO  can  be  described 
by  three  relations  called  "initial  order",  "necessary  constituent",  and 
"essential  predecessor".  These  encode  the  information  described  above,  and 
are  used  to  derive  sets  of  data  flow  information  which  are  used  to  deter¬ 
mine  feasible  code  motions  and  code  eliminations.  Procedures  to  determine 
these  relationships  will  be  supplied  by  the  compiler  writer. 

FLO  will  input  a  program  tree,  and  proceed  down  the  tree,  detecting 
common  subexpressions  and  determining  the  data  flow  sets  mentioned  above, 
which  are  then  used  to  determine  possible  optimizations.  Outputs  of  the 
phase  are  the  program  tree  with  constant  folding  and  dead  code  elimination 
performed  and  lists  of  common  subexpressions  and  feasible  optimizations. 

These:  optimizations  are  those  mentioned  in  the  section  on  optimization 
techniques  (3.2.1). 

4.3.2  CF  -  Constant  Folding 

The  constant  folding  routine  is  unique  in  that  it  is  repeatedly  called 
by  FLO,  ORD,  and  CC  in  order  to  perform  constant  computations  which  appear 
in  the  program  tree.  CF  is  recalled  in  each  of  the  routines  to  perform  those 
computations  uncovered  by  adjustments  made  to  the  tree  by  other  optimizations. 
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Figure  4.4  CF  HIPO  Chart 
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Figure  4.5  ORD  HIPO  Chart 
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Output 
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4.3.3  ORD  -  Tree  Ordering 


The  ORD  module's  purpose  is  primarily  to  perform  a  preliminary  code 
generation,  in  order  to  collect  the  data  required  to  intelligently  select 
among  the  code  movements  found  possible  by  the  FLO  module.  ORD  also  pro¬ 
duces  and  distributes  a  number  of  code-generation  derived  attributes  around 
the  TOOL  tree,  for  use  by  the  following  TNB  and  CG  phases. 

The  preliminary  code  generation  phase,  called  SEL,  uses  an  algorithm 
named  by  Cattell  the  "Maximal  Munching  Method  (MMM)"  algorithm  ;  Cat78|.  In 
essence,  this  algorithm  attempts  to  generate  assembly  code  for  the  largest 
part  of  the  code  tree  (from  the  top  downward)  at  a  time,  and  then  recurse 
upon  the  remaining  unmatched  branches.  Inasmuch  as  register  allocation 
has  not  yet  been  done  the  match  must  make  assumptions  concerning  allocation 
of  the  data  leaves  and  temporary  locations  generated  which  may  prove  to  be 
false;  however,  the  need  is  for  approximate  time/space  values  for  comparison 
purposes,  so  the  assumptions  made  will  probably  cancel  out. 

For  each  code  movement  possibility  indicated  by  FLO,  a  time/space  com¬ 
parison  will  be  made,  and  if  the  code  movement  is  an  improvement,  the  move¬ 
ment  will  be  marked.  The  total  time  and  space  accumulations  (as  well  as 
other  data,  such  as  probable  number  of  executions,  etc.)  will  be  passed  to 
a  user  supplied  tradeoff  routine  which  returns  some  measure  of  quality,  thus 
giving  the  user  control  over  the  goals  of  the  optimization.  In  a  final 
pass,  the  tree  will  be  restructured  by  performing  the  indicated  code  movements. 

The  second  phase  of  ORD,  called  DEC,  performs  some  kinds  of  machine- 
dependent  attribute  determinations  and  tree  decorating.  These  attributes 
include  self-complementing  operations  (i.e.,  x  =  -(-x)),uso  of  special 
register  subsets  (i.e.,  the  M  instruction  on  the  S/370  places  its  result 
in  an  even-odd  register  pair)  and  taking  advantage  of  the  machines  effective 
address  capabilities  to  perfoim  arithmetic. 


32 


The  decoration  of  the  program  tree  with  the  "negated"  attribute  will 
allow  elimination  of  redundant  negation  operations  within  the  tree  (note 
that  "negation"  is  used  herein  generically  to  indicate  any  self  comple¬ 
menting  operation).  At  any  given  node  in  the  tree,  each  of  the  branches  to 
that  node  will  report  back  the  value  of  the  negation  attribute  of  that 
branch.  The  DEC  pass,  upon  arriving  at  that  node  in  an  end-order  walk  of 
the  tree,  will  use  these  values  to  compute  the  "best"  value  of  the  attributes 
to  be  passed  up  the  tree  to  higher  nodes.  This  computation  is  generally 
based  on  the  concept  of  performing  the  minimum  number  of  negations  in  order 
to  satisfy  the  node's  operation. 

The  pass  also  has  the  ability  to  eliminate  negation  nodes,  to  change 
addition  to  subtraction  (and  vice  versa),  and  to  reorder  branch  phasing 
in  order  to  minimize  operations.  An  example  of  negative  propagation  might 
input  the  tree:  . 


(+)  (-) 

Figure  4.6  ORD  Example  Input 

where  the  parenthesized  signs  represent  the  values  of  the  negation  attributes 
at  the  various  nodes.  After  negation  attribute  propagation,  the  tree  would 
resemble : 


Figure  4.7  ORD  Example  Output 


A  similar  (and  simultaneous)  operation  would  decorate  the  tree  with 
attributes  which  indicate  the  desirability  of  having  operands  to  particular 
operations  computed  in  certain  registers.  These  particular  operations  may 
include,  for  example,  integer  multiplication  and  division  on  some  machines, 
which  require  their  inputs  in  a  subset  of  the  available  registers.  For  ex¬ 
ample,  the  following  tree  on  a  machine  like  the  IBM  S/370  might  produce  the 
code  indicated. 


LD  RO, I 
AD  RO , J 
MV  R1  ,  RO 
MP  RO,K 
DV  RO, L 


RO=I+ J 

move  to  odd  reg 


Figure  4.8  Register  Preference  Example 


However,  the  MV  instruction  could  have  been  eliminated  if  the  ADD  node 
had  known  the  result  was  required  in  an  odd  register. 

Finally,  the  DEC  routine  will  search  for  those  nodes  in  the  tree  which 
could  be  subsumed  in  the  effective  address  computation  of  the  machine's 
hardware.  For  example,  the  tree: 
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Figure  4.9  Addressing  Mode  Example 

could  be  performed  in  two  instructions  on  many  machines  if  it  is  recognized 
that  the  result  of  the  substract  operation  should  be  bound  to  an  index  re¬ 
gister,  and  thus  the  add  operation  may  be  performed  as  part  of  the  indexing 
operation  in  the  multiply  operation.  DEC  will  thus  indicate  in  the  attri¬ 
butes  of  the  referencing  operator  above  the  add  operation  the  strong  pre¬ 
ference  for  its  input  to  be  in  an  index  register. 

The  negation  attribute  discussed  above  will  be  of  no  further  use  once 
ORD  is  complete;  however,  the  register  preferencing  attributes  are  needed 
by  the  register  allocation  phase  (TNB)  and  will  remain  until  then. 

Upon  completion  of  ORD  then,  the  program  tree  will  be  in  its  final 
"shape",  reflecting  the  final  layout  of  the  program.  Further  phases  of  the 
compiler  will  not  change  that  basic  shape,  but  rather  change  node  values 
and  attributes. 
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Module  Generator: 
(see  Figure  4.5) 


Compiler  Module: 

Input  Processor 

-  program  tree  from  ORD  -  TNB  routine 

-  LOP 


Output 

-  program  tree 

with  locations 
and  registers 
assigned  to 
temps,  variables 
and  constants 


Figure  4.10  -  TNB  HIPO  Chart 
4.3.6  TNB  -  Temporary  Name  Binding 

The  TNB  module  has  the  function  of  binding  all  user  variables,  local, 
global  and  temporary,  to  real  computer  resources  in  such  a  way  as  to  insure 
the  integrity  of  the  program  semantics,  and  to  provide  the  "best"  use  of 
those  resources.  In  reality,  TNB  must  balance  the  requirements  of  fast  ac¬ 
cess  and  the  usually  limited  number  of  high  speed  data  locations. 

Historically,  register  allocation  has  been  one  of  the  really  tough  com¬ 
putational  problems  in  compiler  theory.  There  are  no  algorithms  currently 
known  which  will  guarantee  optimal  allocation  in  all  usual  compilation  cir¬ 
cumstances,  and  many  of  the  better  algorithms  can  become  extremelv  time  con¬ 
suming  when  some  worst  cases  are  attempted.  Obviously,  what  is  needed  for 
now  is  an  algorithm  which  makes  a  minimal  sacrifice  to  optimality  while  be¬ 
coming  well  behaved  in  a  computational  sense. 

The  register  allocation  scheme  of Jolmsson  ’Joh75:  seems  to  fill  these 
requirements,  and  in  addition,  was  formulated  with  requirements  for  machine 
independence . 
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Johnsscn's  algorithm  is  divided  into  three  phases,  which  we  call  GAT, 
RNK,  and  PAK. 

GAT  is  an  information  gathering  phase;  it  passes  over  the  tree, 
assigning  each  address-valued  node  a  temporary  name  (TN)  represent¬ 
ing  the  location  where  its  value  can  be  temporarily  stored.  In  addition, 
references  to  TNs  and  other  variables  are  noted,  including  whether  the  value 
is  changed  or  simply  used.  When  the  pass  is  complete,  a  list  of  "lifetime 
pairs"  is  computed  for  each  TN  (i.e.,  a  pair  of  points  in  the  program  be¬ 
tween  which  the  TN  is  "alive",  or  in  active  use).  Finally,  preferences  for 
particular  storage  bases  (such  as  those  declared  by  the  access  mode  deter¬ 
mination  part  of  ORD)  are  noted. 

The  RNK  phase  performs  the  primary  analysis  of  the  TNB  module  by  build¬ 
ing  an  interference  and  preference  graph  for  the  program  being  compiled. 

The  interference  graph  links  those  TNs  which  have  overlapping  lifetimes. 
Thus,  two  nodes  which  are  connected  (over  any  path)  in  the  interference 
graph  may  not  be  assigned  to  the  same  physical  location.  The  preference 
graph  links  those  TNs  which  should  be  assigned  the  same  location  in  order 
to  avoid  extra  load  and  store  instructions.  These  links  may  be  weighted  to 
express,  for  instance,  an  increased  preference  for  TNs  within  loops. 

Finally,  the  PAK  phase  distributes  the  known  machine  resources  to  the 
TNs  by  performing  the  "packing  algorithm".  There  is  not  yet  an  optimal 
packing  algorithm  known.  Many  different  algorithms  and  heuristics  are  em¬ 
ployed  at  this  time,  and  further  research  is  being  done  on  the  problem.  A 
good  algorithm  must  meet  four  basic  criteria  (from  Leverett  e.  al.  (LCH791): 

"-  No  two  TNs  which  are  connected  by  an  interference  arc  may  be  packed 
in  (allocated  to)  the  same  storage  location. 

-  The  cost  measure  determined  by  summing  the  relative  costs  of  all 
TNs,  as  derived  from  the  usage  information  discussed  in  previous 
section,  and  from  the  knowledge  about  which  storage  class  each  TN 
has  been  packed  in,  should  be  kept  low  (perhaps  minimized). 
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-  The  profit  measure  determined  by  summing  the  values  of  all  prefer¬ 
ences  arcs  that  connect  two  TNs  packed  ,to  identical  locations  should 
be  kept  high  (perhaps  maximized) . 

-  For  some  storage  classes,  there  may  be  a  cost  associated  with  using 
any  member  of  the  storage  class,  which  is  fixed  regardless  of  how 
the  member  is  used.  For  instance,  a  run-time  convention  for  the 
preservation  of  register  contents  across  routine  calls  may  require 
that  if  a  register  is  used  by  a  routine,  it  must  be  saved  at  the  be¬ 
ginning  of  the  routine  and  restored  at  the  end.  Thus  there  is  a 
cost  measure  determined  by  the  number  of  locations  (of  certain 
classes)  which  are  used  in  a  given  packing;  this  should  be  kept  low.' 

In  a  final  pass,  PAK  will  distribute  its  packing  decisions  throughout 
the  tree,  replacing  variables  and  TNs  with  register  numbers  or  other  sto  ige 
base  locations.  The  program  tree  has  now  been  allocated  in  memory  and  final 
code  generation  may  take  place. 

Module  Generator: 

(see  Figure  4.5) 

Compiler  Module: 

Input  Processor  Output 

-  program  tree  from  CG  -  CG  routine  -  linked  list  of 

-  LOP  instructions 


Figure  4.11  CG  HIPO  Chart 


4.3.5  CG  -  Code  Generation 


The  code  generation  phase  perforins  the  final  pass  on  the  program  tree, 
converting  it  to  actual  assembly  language  code.  It  attempts  to  build  lo¬ 
cally  optimal  sequences  taking  full  advantage  of  the  instruction  set  and 
effective  address  calculations. 

The  primary  algorithm  used  to  perform  this  task  is  Cattell's  MMM  algo¬ 
rithm,  mentioned  earlier  in  the  discussion  of  the  ORD  module.  This  algo¬ 
rithm  attempts  to  pattern  match  the  root  of  the  program  tree  against  an 
ordered  series  of  trees  built  by  the  retargetable  compiler  generator.  This 
list  of  trees  is  ordered  in  such  a  way  that  the  least  expensive  special 
case  instruction  sequences  are  searched  first  in  order  to  satisfy  the  re¬ 
quirements  of  a  given  tree  pattern.  For  instance,  if  the  tree  root  was  an 
add  operator,  the  first  code  segment  to  try  could  be  an  increment  instruc¬ 
tion,  then  an  add  immediate,  then  an  add  register.  Since  address  references 
were  recognized  in  the  ORD  phase  and  appropriate  TNB  assignments  requested, 
most  such  calculations  should  match  effective  address  computations  repre¬ 
sented  by  the  MOP's  access  modes.  Finally,  all  unmatched  subtrees  are  in 
turn  examined  by  MMM  as  it  recurses  on  each  of  them. 

As  an  alternative  code  sequences  are  found  for  each  node  in  the  tree, 
within  the  framework  of  the  tree  and  register  assignments  made  previously 
total  time/space  statistics  are  compiled  and  compared,  insuring  that  the 
optimal  local  code  is  selected.  This  code,  when  output  in  order  by  a  final 
end-order  tree  walk,  may  still  be  subject  to  certain  code  level  optimiza¬ 
tions,  which  will  be  the  subject  of  FOP's  gentle  ministrations. 

4.3.6  FOP  -  Final  Optimization 

After  CG  has  determined  which  instructions  are  to  be  generated,  FOP 
will  perform  final  optimizations  and  emit  machine  code.  Many  of  these  final 
optimizations  are  so  machine  dependent  that  no  formalism  for  FOP  exists,  and 
parts  of  it  will  have  to  be  coded  by  hand.  Some  of  these  optimizations 
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Module  Generator: 

(none  for  FOP) 

Compiler  Module: 

Input  Processor  Output 

-  list  from  CG  -  FOP  processor  -  optimized  list 

-  user  supplied  routines  of  instructions 

in  assembly 
code 


Figure  4.12  FOP  HIPO  Chart 

however,  are  nearly  machine  independent,  and  others  fall  into  general  classes, 
so  that  a  framework  for  FOP  can  be  provided,  which  must  then  be  tailored 
by  hand  for  a  given  machine.  In  general,  the  structure  of  FOP  is  similar 
to  the  final  pass  of  the  BLISS11  compiler. 

The  first  sub-phase  of  FOP  performs  optimizations  which  involve  multiple 
(and  possibly  widely  separated)  instructions.  These  include  cross- j umping 
store/load  pairs,  etc.  Since,  in  some  cases,  these  optimizations  can  make 
other  improvements  possible,  this  phase  will  be  repeated  until  no  optimiza¬ 
tions  remain  to  be  performed.  The  second  sub-phase  will  examine  each  in¬ 
struction  once,  trying  to  replace  it  with  a  cheaper  but  equivalent 
instructions. 

The  third  sub-phase  of  FOP  generates  the  final  compiler  output.  For 
machines,  such  as  the  PDP-11,  with  "span-dependent  instructions"  such  as 
long  vs.  short  form  jumps,  the  proper  alternate  form  will  be  selected  here. 

T.  G.  Szymanski' s  algor ithm,  which  is  efficient  and  optimal  f Szv78l  will  be 
used  to  minimize  the  length  of  these  instructions. 
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4 . 4  The  MOP  Computer  Description 

The  MOP  is  a  functional  machine  description  in  terms  of  input-output 
assertions.  That  is,  it  maps  inputs  in  the  form  of  tree  templates  into 
outputs  which  are  all  machine  instructions  (in  assembly  or  machine  code). 
The  description  itself  is  in  LISP  list  notation  in  which  the  tree  templates 
may  be  easily  encoded.  For  instance  the  notation: 

(;  («-  $1  (-  $1  D)  (+  %N  (LSS  (-  $1  1)  0))  («-  %Z  (EQL  (-  $1  1)  0))) 

is  a  linearization  of  the  tree: 


$11  $11 

Figure  4.13  LISP  notation 


The  semicolon  operator  indicates  a  series  of  alternatives;  in  this  case, 
either  of  the  three  patterns,  if  matched,  will  output  the  same  code.  The 
leftmost  sub  tree  indicates  the  direct  action  of  a  decrement  instruction  (in 
which  the  parameter  "$1"  must  match  a  register),  while  the  other  two  indi¬ 
cate  the  settings  of  condition  codes  %N  and  ZZ  by  the  decrement  action. 

Note  that  each  pair  of  subtrees  represents  the  side  effects  of  applications 
of  the  third. 

The  MOP  is  a  set  of  six  tables  which  describe  different  aspects  of  the 
mach ine : 
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Storage  Bases  (SB)  -  a  list  of  memory  components  in  the  machine,  their 
sizes  and  uses; 

Instruction  fields  (I-flds)  -  a  list  of  fields  used  within  instructions, 
their  sizes,  displacements,  and  types; 

Access  Modes  (AM)  -  a  list  of  ways  in  which  the  various  storage  bases 
may  be  accessed  (e.g.,  direct,  indexed,  etc)  in  symbolic  form; 
Operand  Classes  (OC)  -  a  list  of  sets  of  access  modes,  any  one  of 

which  may  be  applicable  to  a  given  instruction  field,  and  the  cost 
and  format  data  for  the  use  of  each; 

Instruction  Formats  (I-Fmt)  -  a  list  of  possible  formats  which  an  in¬ 
struction  may  be  written  in; 

Machine  Operations  (M-op)  -  the  instruction  I/O  assertions,  including 
cost  and  format  data  for  the  use  of  each. 

There  is  also  a  quasi-machine  independent  table  used  with  the  MOP  de¬ 
scription,  called  the  Axiom  List.  This  is  a  table  of  transformation  func¬ 
tions  which  allow  a  machine  with  a  less-than-comprehensive  instruction  set 
to  use  alternatives.  For  example,  the  axiom  list  includes  DeMorgan's  laws, 
definitions  of  AND  and  OR  operations  in  terms  of  each  other,  etc. 

A  set  of  examples  taken  from  a  description  of  the  PDP8  computer  in 
Cattell  [Cat78]  will  be  presented.  The  complete  description  and  the  Axiom 
List  is  contained  in  Appendix  C. 

An  entry  in  the  I-Flds  list: 

(OP  0  3  0  0) 

describes  the  field  called  "OP",  which  occurs  at  bit  0  word  0  of 
the  instruction,  3  bits  long,  of  type  "opcode". 

An  entry  in  the  SB  list: 

(Mp  256  12  M) 

indicates  the  Mp  (primary  memory)  is  256  12  bit  words  of  type 
"memory". 

Another  example  is  the  program  counter: 

(PC  1  8  P) 
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An  Access  Mode: 


%Mp :  (■  ■  Mp  $l://8  0  12) 

indicates  that  the  AM  "%Mp"  is  a  direct  fetch  from  Mp  of  12  bits 
from  a  constant  8  bit  location  supplied  bv  the  tree. 

The  Operand  Class  "Y"  is  defined  by: 

Y:  (Z8  : :  (EMIT  !  5  0  0 1  $10) 

%Mp  : :  ( EMIT  !  5  1  0  1  $11)) 

That  is,  wherever  the  OC  "Y"  occurs  in  a  M-op,  it  can  be  matched 
either  by  a  tree  leaf  representing  an  eight  bit  constant  (AM  is  Z8) 
or  by  a  direct  memory  access  (AM  is  ZMp)  .  Associated  with  each 
is  a  format  number  (5)  and  space/time  cost  "0  0"  and  "1  0"  respec¬ 
tively  -  note  that  use  of  direct  access  rather  than  immediate 
costs  one  extra  word).  The  final  two  items  for  each  are  formatting 
templates . 

An  example  M-op: 

(IF  (LSS  %Acc  0)  (♦-  %PC  (+  ZPC  1)))  :: 

(EMIT  SKPL  Ill  714) 

This  M-op  could  be  called  by  matching  it  to  the  program  subtree: 


IF 


Figure  4.14  M-op  Matching 

If  this  were  to  happen,  a  SKPL  instruction  would  be  emitted,  at  a  space 
cost  of  1  and  time  cost  of  1,  using  I-Fmt  number  3.  The  "7  1  4"  are  the 
contents  of  3  of  the  fields  in  the  instruction,  fixed  by  the  selection  of 
this  particular  operation.  Note  that  the  SKPL  is  actually  superfluous;  the 
op  code  is  emitted  directly  into  the  I-Fld.  If  input  is  to  go  into  an 
assembler,  the  alphabetic  op  may  be  required. 
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Operator 

Meaning 

#0 

£ds 

Value 

* 

sequence 

* 

none 

. 

dereference 

1 

value 

4- 

assignment 

2 

none 

+  -  * 

'  *  * 

binary 

arithmetic 

2 

value 

- 

unary 

arithmetic 

1 

value 

CALL 

procedure 

1 

+ 

* 

none 

FCALL 

function 

call 

1 

+ 

•k 

value 

UPLOOP 

increment 

4 

none 

DOWNLOOP 

decrement 

4 

none 

CASE 

case 

construct 

2 

+ 

* 

none 

none 


Example 


(;  S,  S,  ..  S  )  perform  state- 
1  l  n 


ments  S^  through  S^  xn  sequence 


(.  A)  contents  of  location  A  . 

(  A  (.  B))  is  A  =  B  (Fortran) 
(+  (.  A)  (.  B))  is  A  +  B 


(-  (.  A))  is  -A 


(CALL  X  A  B)  is  CALL  X  (A,  B) 
(same  as  CALL) 


(UPLOOP  I  J  K  S)  is  FOR  I 
J  TO  K  S;  (Pascal) 


(DOWNLOOP  I  J  K  S)  is  FOR  I 
=  J  DOVNTO  K  S; 


(CASK  I  S(  S2 


S  )  is 
n 


CASE  I  OF  (SEL  ) 


(SEL  V  S)  is  (CASE  I  SJ  S2 


S  )  V 
n 


Figure  4.15  Sample  TCOL.  ,  Operators 

Ada 
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5.  CONCLUSIONS 


t 

1 

The  theory  and  practice  of  compiler  development  has  come  a  long  way 
since  the  first  FORTRAN  compilers.  The  theory  of  lexical  and  syntatic  an- 

1 

alysis  have  been  advanced,  and  the  production  of  those  portions  of  the  com¬ 
piler  have  been  automated.  We  believe  that  we  may  now  also  automate  the 
processes  of  machine  independent  optimization,  register  allocation,  and 
code  generation.  Another  area,  machine  dependent  optimization,  mav  be  at 
least  partially  automated,  but  many  of  these  optimizations  are  still  too 
machine-eccentricity  dependent  to  allow  a  program  to  be  able  to  predict 
what  to  implement  and  how  to  go  about  it.  (It  is  also  hard  for  human  com¬ 
piler  implementors,  and  very  subject  to  experience  on  a  particular  machine.) 

Semantics  analysis  is  the  other  compiler  process  which  does  not  yet 
appear  amenable  to  strictly  automatic  analysis  and  generation.  In  this 
case,  however,'  the  theory  is  advancing  and  the  ability  to  completely  specify 
language  semantics,  and  therefore  the  ability  to  generate  the  appropriate 
output  from  such  a  speci  '  cation ,  seems  to  be  a  near  future  possibility,’. 

We  conclude  that  it  is  possible  at  this  time  to  build  a  comprehensive 
compiler  generator  which  could,  given  a  language  specification  and  a  machine 
description,  generate  a  compiler  for  the  language  on  the  machine.  At  this 
time,  it  would  oe  necessary  to  hand  code  the  semantics  analysis  and  at 
least  part  of  the  final  optimization  pass,  as  well  as  some  parts  of  a  run¬ 
time  library.  We  foresee  no  intractable  problems  generating  an  Ada  or 
J73/I  compiler  using  this  generator. 

There  are  many  areas  which  still  require  study  in  this  field.  Besides 
continuing  work  to  automate  the  semantics  analysis  and  final  optimization 
passes,  the  following  are  topics  on  which  further  research  probably  will 
yield  good  results: 


The  packing  algorithm  used  in  TNB  is  not  optimal,  but  rather 
heuristic.  A  lot  of  pure  topological  research  is  going  on  to 
solve  the  "graph  coloring"  problem,  of  which  this  is  an  example. 

Run-time  monitoring  rKnu73!,  in  which  the  run-time  system  deter¬ 
mines  what  parts  of  the  program  execute  the  most  frequently,  should 
be  examined,  both  as  a  feedback  compiler-writer's  aid,  and  to 
drive . 

Run-time  optimizations,  wherein  the  run-time  statistics  drive 
optimization  in  an  effort  to  increase  the  in-core  efficiency  of  a 
program  which  will  be  used  repeatedly.  One  really  exciting  vari¬ 
ation  on  this  theme  involves  the  optimization  of  micro-code  sup¬ 
porting  the  application  to  be  optimized,  following  run-time 
analysis  of  the  application.  The  microcode  could  be  tailored  for 
a  particular  application  in  this  manner. 

The  inclusion  of  specific  machine  features,  such  as  paging,  cache 
memory,  hardware  stacks  and  queues,  etc.,  whose  impact  on  opti¬ 
mization  strategies  is  not  yet  well  understood. 

Procedure  integration  and  identification,  which  attempts  to 
optimize  across  a  specific  space/time  tradeoff  by  isolating  redun¬ 
dant  code  sections  into  procedures,  and  the  converse  of  expanding 
procedures  in-line. 

Machine  independent  post  optimization  in  which  a  MOP  or  similar 
description  is  used  to  drive  a  general  optimizer.  [Fra79]  describes 
a  general  optimization  which  does  most  of  the  work  of  FLO,  this 
and  similar  techniques  should  be  examined. 


6.  A  DETAILED  COMP i NATION  EXAMPLE 

We  will,  in  this  section,  attempt  to  pursue  a  nontrivial  example 
through  the  various  stages  of  processing  within  a  retargeted  compiler.  The 
example  is  written  in  PASCAL  and  is  not  meant  to  be  a  functionally  meaning¬ 
ful  program  (see  Figure  6.1).  After  the  front-end  pass,  it  has  been  expanded 
into  an  equivalent  TCOL  tree  with  accompanying  symbolic  information  (see 
Figure  6.2). 

There  are  several  things  to  notice  in  this  front-end  conversion.  The 
tree  is  of  course  built  by  the  TRL  routines  under  the  direction  of  the  user 
supplied  SEM  phase.  Note  that  the  array  accesses  have  been  expanded,  by 
making  assumptions  covering  both  the  language  interpretation  of  arrays  and 
the  machine.  The  symbol  table  has  been  consulted,  in  order  to  find  the  value 
of  the  lowest  array  bound  of  each  array. 

The  semantic  routines  could  have  as  easily  prepared  a  call  to  a  gen¬ 
eral  array  referencing  subroutine,  if  the  language  (for  example)  allows 
dynamic  arrays. 

The  symbol  table  (Figure  6.3)  initially  contains  variable  types  and 
bounds  (for  arrays)  and  values  for  constants. 

When  FLO  is  called,  several  things  happen.  Constant  folding  is  called, 
flow  analysis  identifies  constants  and  dead  variables,  and  the  tree  is  threa¬ 
ded  with  common  subexpressions.  These  changes  are  shown  in  Figures  6.4  and 
6.5. 


Figure  6.4  is  unchanged  from  6.2,  except  for  the  addition  of  common 
subexpression  chains.  These  chains  will  be  used  by  ORT)  in  eliminating  re¬ 
dundant  computations.  Figure  6.5  shows  the  possibilities  for  constant  fold¬ 
ing,  constant  propagation,  code  motion  and  strength  reduction.  The  "+0" 
terms  will  be  removed  when  they  are  recognized,  and  the  constant  selector 


48 


VAR:  A 

:  ARRAY 

[  0 . .  10  ] 

OF 

INTEGER; 

B 

:  ARRAY 

CO. . 151 

OF 

INTEGER; 

C 

,  F,  D: 

INTEGER; 

Q 

,  R,  K,  N 

,  LCOUNT, 

MTYPE,  E,  WL 

CONST: 

MTYPE  = 

360; 

BEGIN 

LCOUNT: 

=  5;  R  : 

=  0;  C  := 

0; 

o 

II 

o 

*3 

READ  (Q,N) ; 

FOR  K  :=  N  DOWNTO  0 
BEGIN 


R  :=  R  +  A 

[2  *  Kj  ; 

C  :  =  C  +  A 

[3  *  K  +  1] 

F  :=  F  +  B 

[3  *  Kl  ; 

FOR  I  :=  0 

TO  K 

BEGIN 

D  :=  D 

+  I  +  C; 

E  :=  E 

+  LCOUNT; 

END 

D  :  =  D  *  C 

y 

END 

IE  MTYPE  OF 

360:  WL  : 

=  32; 

1130:  WL  : 

=  16; 

6000:  WL  : 

=  60; 

END 


WRITE  ('WORDLENGTH  IS',  WT.) 


Figure  6.1  Example  Code  Fragment 


Bounds 


Name 

Type 

Low  High 

Value 

K 

INT 

N 

INT 

B 

INT  ARRAY 

0  15 

A 

INT  ARRAY 

0  10 

C 

INT 

F 

INT 

I 

INT 

D 

INT 

E 

INT 

LCOUNT 

INT 

MTYPE 

INT  CONST 

360 

WL 

INT 

R 

INT 

Figure  6. 3 

Initial  Symbol 

Table 

for  the  "CASE"  expression  will  cause  it  to  be  collapsed  to  (-*-  WL  32).  Since 
this  is  the  only  assignment  to  WL,  all  occurrences  of  WL  will  be  replaced  by 
a  constant  32  and  this  assignment  will  be  eliminated.  It  is  recognized  that 
"2  +  N  *  ABS(Q)"  is  invariant  with  respect  to  the  loop  it  appears  in,  and 
its  possible  motion  out  of  the  loop  is  passed  to  ORD.  Finally,  "2  *  K"  and 
"3  *  K"  are  recognized  as  candidates  for  strength  reduction. 

Figure  6.6  shows  the  program  tree  after  ORD  has  determined  and  per¬ 
formed  feasible  optimizations.  The  expressions  "2  *  K"  and  "3  *  K"  in  the 
outer  loop  have  been  replaced  by  subtractions,  with  T1  and  T2  being  initialized 
outside  the  loop  ,  and  the  expression  A  +  1  has  been  replaced  by  a  constant 

with  the  value  of  A  +  1  (note  that  "A"  is  a  location  constant).  T3  is  set  to 
the  value  of  the  loop- invar iate  expression  outside  the  loop. 
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ORD  must  finally  try  to  set  some  attributes  in  such  a  way  that  optimal 
use  is  made  of  the  machine's  addressing  hardware.  If  we  allow  the  following 
access  modes:  .  , 


direct : 


indirect : 


M 


immediate : 


n 


indexed : 


A 


(subcase : 


I  > 


Y 


I 

X 


where  C  is  a  constant,  M  is  a  memory  address  constant  (possibly  relocatable) 
and  X  is  an  index  register  constant.  Access  Mode  determination  will  search 
the  tree  for  such  patterns  and  apply  attributes  (and  possibly  perform  some 
rearranging)  in  order  to  save  instructions.  The  result  is  that  T1  and  T2 
are  bound  to  index  registers,  as  also  shown  in  Figure  6.7. 


For  this  example  we  will  define  the  following  properties  for  the 
integer  instructions: 


add:  r  +■  r  +  x 

sub:  r  r  -  x 

mul:  r  *  r  *  x 

P  o 

div:  r  •*-  r  /  x 

o  p 


where  r  is  any  register,  x  is  any  register  or  memory  location,  r^  is  an  even- 
odd  register  pair,  and  r^  is  the  odd  register  of  that  pair.  In  order  to 
effect  proper  register  preferencing,  we  will  use  two  attributes  to  each  node 
of  the  tree: 


preference/Pref^  :  =  odd/O,  even/E,  pair/F, 

don't  care/P,  memorv/M 

result/Res^  :  =  0,E,P,M,  anv  register/P, 

register  2/2 
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At  any  given  node,  then,  the  attributes  of  result  will  be  passed  up  the  tree, 
while  preferences  for  the  operands  will  be  passed  down,  while  the  attempt 
will  be  made  to  match  the  result  attribute  to  the  requested  preference.  We 
can  then  formulate  the  computations  on  the  attributes  as  a  function  of  the 
op  code: 

*  :  Pref.*-  Pref  0,  Res..  *-  P 

Li  K  U 

/  :  Pref,*-  P,  Pref  *-  D,  Res,,*-  0 

L  K  U 

These  two  are  relatively  straightforward  ,  since  the  requirements  are  strict. 
Multiply  requires  at  least  one  of  its  operands  in  an  odd  register,  and  re¬ 
turns  a  pair;  the  dividend  must  be  in  a  pair,  the  divisor  may  be  anywhere, 
and  the  result  will  be  in  an  odd  register. 

:  Pref  *-  Pref  Pref  *-  D 
L  U  j  K 

ReSy  -  IF  ResL  =  M  THEN  Prefy  ELSE 

(IF  ResT  =  P  THEN  0  ELSE  Res  ) 

Li  Li 

+  :  Pref  *-  Pref  *-  Pref 
L  K  U 

Res.*-  IF  Res  =  Pref  THEN  Res  ELSE 
U  L  U  L 

(IF  Res„  =  Pref  THEN  Res„  ELSE 
R  U  K 

(IF  Res.*  M  THEN  Res  ELSE 

Li  Li 

(IF  Res„*  M  THEN  Res,.  ELSE 
K  K 

(IF  Prefy  =  P  THEN  E  ELSE 

(IF  Prefy*  D  THEN  Prefy  ELSE  chose  arbitrarily  ))))) 

The  latter  two  productions  for  result  attributes  are  more  complicated 
because  the  instructions  are  more  flexible;  they  may  leave  results  in  many 
different  places,  depending  on  where  their  operands  are  located. 

Finally,  we  need  to  determine  productions  for  some  other  operators: 
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*  :  Pref  "-  D  (no  result) 

K 

.  :  Pref^"-  D,  Res^"-  R 

CALL  :  Pref  (for  each  R  branch)"-  M 

R 

FCALL  :  Pref  <-  M,  Res.,"-  2 

K  IJ 

The  last  referring  to  the  system  conventions  that  FCALL  leaves  its  value  in 
register  2  in  all  cases.  (Then  the  attributes  are  distributed  over  the  tree 
(i.e.,  it  is  "decorated")  the  result  is  Figure  6.7.  Note  that  there  are 
several  disagreements;  however,  all  but  one  result  may  be  presented  in  a 
compatible  way  to  the  preferences  -  the  one  non-compatibility  results  from 
the  result  of  the  FCALL  being  in  register  ,  whereas  an  odd  register  was 
desired.  This  incompatibility  will  be  relieved  during  code  generation. 

Register  allocation  will  now  attempt  to  bind  the  various  nodes  to 
machine  locations.  Figure  6.8  shows  the  tree  at  this  point,  decorated  with 
temporary  names  and  with  basic  blocks  delineated.  The  attribute  analysis 
made  earlier  determined  that  Og  must  be  R2  and  that  Q2 >  Q4 »  and  °37 
must  be  odd  numbered  registers.  Furthermore,  Q14,  Q2q  an^  ^26  must  i-ndex 
registers . 

The  initial  pass  of  register  allocation  now  proceeds  through  the  tree, 
collecting  lifetime  data  on  all  the  variables  and  temporaries,  and  then  the 
later  pass  allocates  on  the  basis  of  that  data.  In  our  example  the  allocator 
might  find  that  it  would  be  best  to  keep  the  loop  indicies  in  registers.  If 
the  machine  had  four  registers  (RO  through  R3) ,  and  Rl,  R2,  and  R3  could  be 
index  registers,  then  a  possible  allocation  is  shown  in  Figure  6.9.  All  of 
the  nodes  remaining  unmarked  are  internal  to  effective  address  computations. 

Code  generation  makes  the  heaviest  use  of  the  machine  description 
provided  by  the  user.  We  will  suppose  the  L-ops  shown  in  Figure  6.10 
have  been  provided.  The  MMM  algorithm  now  proceeds  to  trv  to  match  the 
highest  nodes  on  the  tree  to  patterns  in  the  LOP  table.  The  CALL  node  is 
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(<-  c  1 : REG  0)  (EMIT  [  CLR  $U) 

(<  $ 1 : REG  $2 : REG)  (EMIT  i MVR  $1,  $2]) 

('  $ 1 : REG  $2 :MA)  (EMIT  [ LD  $1,  $2]) 

(*  $  1 :MA  $2 : REC)  (EMIT  [  STA  $1,  $2J) 

(*  $  1 : REG  (+  $  1 : REG  1))  (EMIT  [INC  $1]) 

(<  $  1 : REG  (+  $  1 : REG  $2:#16))  (EMIT  [ADI  $1,  $2]) 

(<  $1:R EG  (+  $1 : REG  $2:MA))  (EMIT  !  ADD  $1,  $21) 

(■e  $  1 :  REC  (-  $1 :  REG  1))  (EMIT  [  DCR  $1]) 

(-  $  1 : REC  (-  $  1 :  REG  $2:#16))  (EMIT  [ADI  $1,  -  $2  j) 

(i  $  1 : REG  (*  $  1 : REG  2))  (EMIT  [SLA  $11) 

('-  $  1 :  RECP  (*  $1 :  REGO  $2:MA)>  (EMIT  [MPY  $1,  $2]) 

(CALI.  $i :  NAME  $2:LIST)  (EMIT  [  JSR  $1  ;  $2]) 

(-  $  1 : REG2  (FCALL  S 1 : NAME  §2:LIST))  (EMIT  [JSR  $1  ;  $2J) 
(UPLOOP  $  I : REG  $2:MA  $3:MA  $4 : TREE) 

(EMIT  [ LDA  $1,  $2  ;  GENLBL  $5  ; 

CPR  $1,  $3  ;  BGR  $6  ;  $4; 

INC  $1  ;  BRU  $5  ;  GENLBL  $6]) 
(DOWNLOOP  S 1 : REG  $2:MA  $3:MA  $4 : TREE) 

(EMIT  I  LDA  $1,  $2  ;  GENLBL  $5  ; 

CPR  $1,  $3  ;  BLS  $6  ;  $4  ;  DCR  $1 
BRU  $5  ;  GENLBL  $61) 


Figure  6.10  Example  LOP  Description 
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matched  immediately;  the  generated  code  is  temporarily  linked  to  the  tree 
for  later  collection  and  the  algorithm  proceeds  to  the  assignment  of  2  *  N 
Tl.  This  is  a  little  harder,  since  no  tree  directly  batches  the  node  ( T 1  is 
a  memory  location).  The  search  algorithm  will  match  the  SLA  instruction  and 
then  attempt  to  recurse  on  the  rest,  finding  the  STR  instruction.  Note  that, 
because  of  the  ordering  of  the  LOP,  the  SLA  was  generated  instead  of  an  MPY 
instruction. 

The  algorithm  will  proceed  through  the  rest  of  the  tree  in  a  similar 
manner.  Finally,  the  algorithm  will  walk  the  tree,  building  the  doubly 
linked  list  of  instructions  in  correct  order  (Figure  6.11). 

After  code  has  been  generated,  FOP  performs  post  optimization  on  the 
code.  Because  of  the  simplicity  of  this  example,  cross-iumping,  simplifi¬ 
cation  of  operators,  and  span-dependent  instruction  optimization  are  not 
performed.  The  single  post  optimization  done  is  the  elimination  of  the 
redundant  operation  "LD  Rl,  T2",  which  is  marked  with  an  asterisk. 


I 


JSR  READ 


CLR 


LI: 


JSR 

REA1 

3 

CLR 

R2 

it 

OPENING  CODE 

FOR 

QLIST 

L3: 

CPR 

R2, 

K 

it  UPLOOP 

LD 

Rl, 

N 

BGR 

L4 

SLA 

R1 

LD 

RO, 

D 

ST 

Tl, 

Rl 

ADD 

RO, 

I 

LD 

Rl, 

N 

ADD 

RO, 

C 

MPY 

Rl, 

THREE 

ST 

RO, 

D 

ST 

T2, 

Rl 

LD 

RO, 

E 

JSR 

ABS 

ADI 

RO, 

5 

QLIST 

ST 

RO, 

E 

MVR 

R3 , 

R2 

INC 

R2 

it 

CLOSING  CODE 

FOR 

MPY 

R3, 

N 

BRU 

L3 

# 

UPLOOP 

ADI 

R3, 

2 

L4: 

LD 

Rl, 

D 

ST 

R3, 

T3 

MPY 

Rl, 

C 

LD 

R3, 

N  it 

OPENING  CODE 

ST 

Rl, 

D 

it 

FOR  DOWNLOOP 

LD 

Rl, 

Tl 

ADI 

Rl. 

-  2 

CPR 

R3, 

ZERO 

ST 

Rl  , 

Tl 

BLS 

L2 

LD 

Rl, 

T2 

LD 

Rl, 

Tl 

ADI 

Rl, 

-  3 

LD 

R2, 

R 

ST 

Rl, 

T2 

ADD 

R2, 

A  (Rl ) 

DCR 

R3 

it 

CLOSING  CODE 

FOR 

ADD 

Rl, 

C 

BRU 

LI 

it 

DOWNLOOP 

ST 

R2, 

C 

L2: 

JSR 

WRITE 

'LD 

Rl, 

T2 

WLIST 

LD 

R2, 

F 

. 

ADD 

R2, 

B  (Rl) 

. 

ST 

R2, 

F 

ZERO  DATA  0 
THREE  DATA  3 
QLIST  DATA  1 
DATA  Q 
WLIST  DATA  2 

DATA  ’ - ' 

DATA  32 

Figure  6.11  Code  Generator  Output 
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I n t roduet  1  on 


This  paper  briefly  describes  a  number  of  computer  descrip* 
1 1  on  languages  (CDl's).  Rather  than  give  a  separate  description 
of  each  language#  the  discussion  focuses  on  groups  of  eharac* 
terlstlcs.  The  languages  are  described  and  compared  In  terms  of 
each  group*  This  should  serve  to  make  the  presentation  easier  to 
comprehend  and  allow  the  reader  to  select  those  aspects  of  COL's 
of  most  interest  to  him.  Section  2  presents  the  procedural 
languages*  while  Section  3  presents  the  nonprocedural  languages* 
Each  language  group  Is  summarized  separately. 

Because  of  the  large  number  of  existing  CDL's#  this  paper 
does  not  try  to  be  exhaustive#  though  an  effort  was  made  to  In¬ 
clude  languages  with  wide  applicability.  Section  4  gives  some  of 
the  languages  that  were  left  out  and  some  justification  for  doing 
so.  Section  5  discusses  two  languages*  ConLan  end  RTS  III*  that 
look  promising  and  ambitious*  but  which  ere  still  being  defined* 
Section  6  gives  some  conclusions  and  summery  remarks.  Section  7 
summarizes  the  languages  In  a  table  for  easy  reference  and  com- 
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pari  son 


Precsaural  Language* 


Tne  distinguishing  feature  of  a  orocedural  1 anguaqe  is  that 
it  attributes  a  significance  to  the  lexica'  order  of  the  action 
statements.  Generally,  the  action  statements  are  urouoeg  into 
"steps*  (or  "time  blocks").  The  statements  within  a  qiven  group 
are  assumed  to  operate  in  parallel.  The  groups  are  performed  in 
order  as  they  are  listen  in  the  text.  Generally,  different  se- 
quences  of  groups  can  operate  in  parallel.  This  ser i es-naral 1  el 
sequencing  structure  can  generally  De  nested  to  eny  deoth,  Some 
1  enqueues  have  more  general  parallelism  constructs. 

The  languages  considered  here  are  Ibf1  fbN71],  4Pi>L  fL’arnft], 
LAlSO  [  S  H  7  S  a )  ,  SMITF  (  T  P  a  7  7 )  ,  ana  l.  C  u  (!»■*]  .  The  lanqueaes  are 
described  ang  compared  on  the  basis  of  a  few  characteristics  at  a 
time. 


Purpose,  Description  Type  and  Level  of  Description 

Hrst,  the  languages  are  compared  on  the  basis  of  purpose, 
description  tvpe,  ano  level  of  description, 

Purpose  here  refers  to  the  applications  a  lanquaoe  ’s  tar¬ 
geted  for,  A  I anauage  desiooer  may  focus  on  aoals  for  a  language 
that  are  not  directly  related  to  the  taropr  arr 1 (cat i nrs  (reada¬ 
bility,  writaoility,  careful  treatement  of  tirr«,  powerful  compo¬ 
sition  constructs,  extensibility,  etc.).  hany  of  the  areas  ad¬ 
dressee  by  these  goals  ara  discussed  later.  Others  ere  too  sub- 
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jective  for  *vs  te^it  Ic  fv#lu«Hon  ana  cono«pison,  Thus#  toireone 
interestad  *  n  a  co*er*f'ePsi  v«  treatment  of  the  objectives  of  a 
lanquage  is  best  advised  to  refer  to  toe  language  defining  decu- 
meot . 

description  tyee  refers  to  the  general  aspects  of  the  ways  a 
language  car  be  used  to  deacrloe  a  digital  system,  First*  a  des¬ 
cription  mav  emphasize  the  behavior  of  a  system  (the  actions  per¬ 
formed  ov  the  system)  or  its  structure  (the  components  and  their 
re  1  at  1 onsh 1 ps ) ,  while  pursuing  either  of  these  orientations  or 
some  combination,  a  description  may  give  a  specification,  treat¬ 
ing  the  system  as  a  "black  bo*"  and  giving  only  its  I/O  behavior. 
Alternatively,  a  descriotion  may  qive  an  i mn 1 ement at i on ,  minutely 
detailing  the  behavior  and/or  structure  of  the  system.  It  should 
be  noted  that  a  language  can  allow,  or  insist  on,  redundancy  in 
the  form  of  alternative  descriptions  for  a  system  or  subsystem. 
The  alternatives  mav  have  different  orientations  and /nr  different 
degrees  of  detail.  This  redundancy  "av  be  exploited  through 
human  or  machine  consistency  checking.  To  summarize,  description 
tvpe  includes  the  orientation  (structure  vs.  behavior),  level  of 
detail  (specification  tc  i mn 1 emt a t i on  1 ,  ana  redundancy  possible 
with  a  l anguare , 

The  level  of  a  description  refers  to  the  level  of  orimitivaa 
used  in  writing  the  description.  The  level  may  t*  component  cir¬ 
cuit,  s w i t c h i n q  circuit,  register  transfer,  TSP,  or  pMS.  The 
component  circuit  level  deals  with  diooes,  transistors,  resis¬ 
tors,  etc.,  and  their  i n t e rc onnec t i one  *  The  switchino  circuit 
Irvel  Heel*  with  logic  gates  and  flip-flop*.  hegister  transfer 
primitives  include  registers,  combinatorial  expressions  ano  dis- 
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Crete  date  end  control  operation  steps.  The  ISP  (instruction  set 


processor)  Primitives  ere  i nt e rpret at i on  rules#  the  memories  vi¬ 
sible  to  the  programmer  end  instructions  (in  terms  of  visible 
memories).  The  PMS  level  describes  the  gross  components  of  a 
system  (Processors#  Memories#  Switches#  devices#  etc.)  giving 
their  generel  capabilities  and  their  i nt er rel at i onsh i ps .  The 
reader  should  oe  careful  to  distinguish  level  of  description 
from  level  of  detail.  The  two  do  correlate  weakly#  but  the 
letter  is  concerned  with  the  kinds  of  primitives  available  for 
writing  a  description#  while  the  former  is  concerned  with  how  de¬ 
tailed  a  description  is.  For  a  more  through  discussion  of  des¬ 
cription  levels#  the  reader  should  see  IBN71)  and  (Ber75). 


ISI* 

The  language  ISP  was  developed  for  exposition. 
Particularly#  its  initial  purpose  was  to  concisely  describe  the 
instruction  sets  for  various  diverse  computers.  It  is  oriented 
toward  describing  behavior  with  some  aspects  of  the  structure 
being  implied.  ISP  is  useful  on  all  levels  of  detail#  from 
top-level  specification  to  e  detailed  discription  of  an  implemen¬ 
tation.  ISP  does  not  allow  for  redundancy.  ISP  in  mainly  a  re- 
giatar  transfer  language,  though  it  can  be  uaed  at  the  ISP  level 


of  desc  r i pt i on 


APOL 


>► 


APOL  n»*  designed  for  design#  simulation#  and  documentation. 
It  is  oriented  toward  behavioral  descriptions.  The  descriptions 
ere  close  to  being  e  specification.  APOL  provides  register 
transfer  level  primitives.  Redundant  descriptions  ere  not  el* 
1  owed. 


lalsd 

LALSD  was  Intended  fcr  use  in  documentat i on#  simulation#  and 
design.  It  is  oriented  toward  describing  the  structure  of  a  ays* 
tern.  The  description  may  be  at  any  level  of  detail  from  specifi* 
cation  to  implementation.  At  any  level  of  detail  above  implement 
tation#  a  high»order  language  may  be  used  to  describe  the  behevi* 
or  of  some  Parts  of  a  system.  Redundant  descriptions  are  not  el* 
lowed.  LALSO's  primitives  are  on  the  register  transfer  level. 


SHITE 

SHITE  was  developed  for  use  in  developing  emulators  to  run 
on  a  QH*1,  SMITE  is  oriented  toward  behavioral  di esc r i pt i one. 
It  can  be  used  for  specifications  through  implementation  descrip* 
tions.  No  redundancy  is  allowed,  SMITE'S  primitives  are  on  the 
register  transfer  level. 
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LCD 


LCO  la  intended  fop  use  with  comruftr  design.  It  is  orient¬ 
ed  toward  behavioral  oa sc r i pt i on* .  It  Is  not  suited  to  writing 
high  level  epee i f ♦ cat i ona ,  but  it  can  suppress  some  detail* 
though  the  1 enauage  is  mainly  appropriate  to  describing  specific 
implementat i ons,  Redundancy  is  required,  Fach  module  must  have 
at  leaat  a  general  description  of  behavior.  Each  module,  except 
on#  on  the  lowest  level,  must  also  have  a  Description  of  the  data 
objects  and  control  sequences  which  implement  its  behavior,  LCO 
ia  mainly  a  register  transfer  level  lanouage,  tut  can  be  used  as 
an  ISP  lave)  language. 


Date,  Carriers,  end  Assignments 

Now  the  languages  are  compared  on  the  basis  of  the  data  fa¬ 
cilities,  carriers  end  assignments  they  provide.  Data  suooorted 
foe  compilation  and  in  the  described  machine  are  di st i nc ui shed. 
Carriers  are  the  elements  of  a  system  that  hold  and  transmit 
data.  They  may  simolv  be  terminals  (wires  or  connection  points) 
which  retain  a  given  value  only  so  Iona  es  that  value  is  applied 
to  them.  Busses,  which  might  be  considered  a  variety  of  termi¬ 
nal,  sometimes  recisve  special  support  from  languages.  This  and 
the  fact  that  they  are  so  widely  used  merit  busses  beino  singled 
out  as  a  carrier  type  when  a  language  supports  them.  Finally,  a 
carrier  may  be  a  reaister,  an  element  that  retains  a  value  over 
time  without  an  input  being  erplied, 
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Assignments  nay  serve  several  purposes  In  a  computer  des¬ 
cription.  They  »ey  represent  setting  some  register  or  applying 
an  Inout  to  a  terminal*  Assignments  may  set  the  value  of 
compile-time  bookkeeping  variables.  Assignment  mav  be  used  to 
represent  multiplexing  or  pulsing.  Finally*  assignment  may  re¬ 
present  renaming  of  some  structure.  £ech  one  of  these  functions 
may  have  a  separate  symbol*  For  a  thorough  discussion  of  the  as¬ 
signment  statement*  see  IJS771  . 

IS° 

ISP  supports  bits  ana  Integers  as  data  both  durlny  compila¬ 
tion  and  In  the  described  machine*  Both  constants  end  variables 
are  supported.  Vectors  and  matrices  of  bits  are  supported.  A 
vector  of  bits  or  a  row  of  a  matrix  may  be  used  as  an  Integer. 
Data  format  description  tools  have  never  been  defined  for  ISP. 
Indexing  and  renaming  are  supported  for  accessing.  An  Index  ex¬ 
pression  may  specify  a  range  or  list  of  Indexes.  Any  data  object 
may  appear  in  an  index  expression.  Any  data  object*  Indexed  or 
not*  or  collection  of  them*  may  be  oiven  a  name.  The  renaming 
may  also  be  used  to  view  the  object  or  collection  as  an  array  or 
matrix  with  Index  ranges  of  its  own.  Thus*  names  may  be  qlven  to 
subregisters  and  collections  of  registers.  ISP  primitive  opera¬ 
tions  Include  the  normal  arithmetic  operators*  logical  AND*  OR* 
exclusive  PR*  equivalence  and  NOT,  The  primitive  operators  also 
Include  ell  the  relational  operators  and  a  rich  sat  of  shift  op- 
orators.  Fxpressions  may  ba  arbitrarily  comolax.  The  only  car¬ 
riers  ISP  supports  ere  registers.  Renaming  ang  transfer  etslgn- 
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wen t a  ar«  supported 


APDL 

APOL  provides  binary#  octal#  and  decimal  data  objects.  Also 
supported  are  switches#  data  objects  takinq  on  statement  labels 
as  values.  The  numeric  objects  may  be  composed  into  vectors  and 
matrices,  Matrix  rows  anc  vectors  may  be  treated  as  positive  in¬ 
tegers,  No  description  of  abstract  formats  is  Possible.  The  in¬ 
dexing  and  renaming  capabilities  ere  analogous  to  ISP#  exeeot 
that  an  index  for  referencing  a  row  of  a  matrix  may  only  specify 
a  single  row. 

The  boolean  operators#  AND,  OR#  NOT,  and  exclusive  OR,  are 
provided.  They  treat  0  as  true  and  1  as  false.  The  standard  ar¬ 
ithmetic  operators  are  provided  for  integers#  and  all  the  stan¬ 
dard  relational  operators  are  provided,  Darringer's  article 
(Dar681  does  not  specify  any  expression  cnmoosition#  but  does 
seem  to  allow  their  incJy*ion  in  a  1 anguaoe  i mp 1 ement at i on. 
Registers  are  the  only  carriers  supported#  enn  transfer  is  the 
only  assignment  supported. 


LALSO 

The  only  data  type  supported  by  LALSD  is  bits.  hits  may  be 
composed  into  vectors.  Collections  of  objects  and  vectors  can  be 
renamed  as  vectors.  fxplicit  address  registers  must  be  given  for 
"memories"#  arrays  of  multi-bit  registers.  Indexing  of  memories 
must  use  this  address  register.  Primitive  operations  include  in- 


c re«ent #  decrement,  shift,  complement  and  concatenation  for  vec¬ 
tors#  treating  vectors  as  integers  when  appropriate,  AND#  OR, 
NOT  and  exclusive  OR  are  provided  for  hits.  The  full  range  of 
relational  operators  are  available  which  treat  vectors  as  in* 
tagers.  Conditions  may  be  arbitrarily  eomolex  combinations  of 
bit  and  relational  operations. 

Registers  and  terminals  are  supported  as  carriers. 
Assignments  can  be  used  for  connection.  Transfer  is  represented 
with  a  command  that  looks  like  a  proeeedure  call, 

SMITE 

SmITE  provides  bits  as  a  primitive  data  tyoe.  They  can  be 
composed  into  vectors  end  matrices.  Formats  may  be  described. 
They  give  names  to  subworos  of  abstract  structures.  These  named 
subwords  can  then  be  used  to  reference  subworos  of  concrete  ob¬ 
jects,  Also,  specific  sections  of  specific  objects  can  be  given 
uniaue  names.  Any  value  can  be  used  as  an  Index,  Primitive  op¬ 
erations  include  addition,  subtraction#  a  full  complement  of  re¬ 
lational  operators#  AND#  OR#  NOT,  exclusive  OR#  and  concatena¬ 
tion,  These  operations#  together  with  assignment#  may  be  com¬ 
posed  arbitrarily  into  expressions#  so  long  as  each  subexpression 
returns  a  sinale  value.  Assignment  returns  the  value  assigned. 
Operations  are  evaluatec  from  right  to  left  normally#  but  oar- 
entheses  may  be  used  to  overide  the  usual  interpretation. 

Only  register  type  carriers  ere  supported#  end  transfer  is 
the  only  assignment  supported. 
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'..CD 

LCD  provide*  support  for  bits.  a  bit  may  take  on  a  value  of 
0#  1/  or  UNDEFINED,  ICO  also  supports  variables  that  take  on 

symbolic  values.  These  variables  may  be  tested  for  equality  or 
inequality  only.  This  support  is  helpful  for  simulation  using 
symbolic  execution.  Vectors  and  matrices  of  hits  may  he  speci¬ 
fied.  Concatenation#  AM),  nfi#  NOT#  and  the  standam  arithmetic 
operators  are  provided.  The  arithmetic  operators  treat  vectors 
and  rows  of  matrices  as  integers,  AND  reduction  of  vectors  is 
also  provided.  Symbolic  manipulation  of  symoolic  values  is  pro¬ 
vided.  An v  expression  may  be  used  as  an  index.  Expressions  may 
be  arbitrarily  complex. 

Busses#  registers#  end  terminals  are  supported  es  carriers. 
Assignment  to  a  register  is  a  transfer.  Assianment  to  a  terminal 
'maintains  the  assigned  velue  in  the  tar set  for  a  time  step. 


Modularization,  Control  and  Its  Relation  to  Data,  and  Time 

This  section  deals  with  a  set  of  c h a rac t e r i s t i c s  of  how  a 
language  describes  the  decomposition  of  structures  and  the  decom¬ 
position  and  control  of  processes.  These  c h a r sc t e r i s t i c s  are: 
1)  the  modularization  concents;  ?)  the  control  constructs;  3) 
the  treatment  of  time;  and  4}  the  relationship  between  control 
end  data. 

It  is  useful  to  modularize  a  system  in  ont*  time  and  space, 
Soace  modu I  a r i z at i on  is  seen  in  the  partitioning  of  a  avstem  into 
memories#  controls#  ALU's#  and  busses.  Time  modu 1  a r i ? a t  i  on  is 
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seen  in  the  definition  of  instruction  fetch  cycles,  interface 
protocols#  and  inatruction  decode  processes, 

A  language  must  provide  ways  of  describing  the  processes  and 
atructure  that  m#ke  up  a  machine,  For  nontrivel  processes#  me¬ 
chanisms  must  be  provided  for  making  choices  and  specifying  iter¬ 
ation,  Since  comou\.-rs  make  major  use  of  parallelism,  a  l  a  n  g  u  a  g  e 
must  he  able  to  express  parallelism  and  coordination  of  parallel 
processes,  A  description  of  hardware  structures  must  include 
descriptions  of  their  i nte rconnect i onf ,  Finally,  languages  must 
also  provide  forms  for  excreasing  modu l a r i z at i on , 

Connection,  sequencing,  iteration,  decision,  and  modulariza¬ 
tion  are  more  concerned  - i t h  the  organization  of  the  actions  ana 
components  of  e  machine  than  with  what  the  actions  and  components 
actually  are,  0 rgan i zat 1 ona 1  forms  and  mechanisms  are  refereo  to 
as  control  constructs.  The  kinds  of  control  constructs  provideo 
by  a  language  greatly  affect  its  power  sod  esse  of  use.  For  in* 
stanc-#  a  aaries  of  if  statements  can  be  used  to  make  a  choice 
among  several  alternatives,  but  s  CASE,  or  DECODE  statement  for 
the  same  deciaion  is  much  easier  to  write  end  clearer  to  under¬ 
stand,  Macros  can  be  very  useful#  as  is  the  ablility  to  apply 
descision  mechanisms  to  structure.  The  constructs  then  become 
ccmpile-time  mechanisms.  Iteration  can  be  a  particularly  power¬ 
ful  ana  clear  way  of  describing  a  large  regular  structure.  Then 
there  ere  structure  and  process  control  constructs,  which  can  be 
divided  into  seauencirg  end  synchronization  constructs, 
Seauencinq  constructs  include  selection  and  FOhx, 
Synchronization  constructs  include  JOIN  ano  signal-welt. 
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Time  1#  of  nre*t  importance  to  any  computer  design. 
Languages  provide  various  ways  of  measuring  and  describing  tim- 
i  ng. 

A  common  cha r ac t er i s t i c  of  the  languages  Described  in  this 
paper  is  that  they  provide  for  the  separation  of  control  ana 
dete.  The  dste  ere  the  memories  and  terminals  and  the  control  is 
the  processes.  It  is  alsc  important  that  the  control  ana  aata  he 
able  to  interact.  It  is  convenient  to  save  the  control  state  as 
date.  Control  state  changes  must  somptimes  be  ased  on  data. 
Thus  the  Possible  interactions  of  control  ana  data  for  a 
languages  are  discussed, 

ISP 

ISP  provides  for  *odu 1  a r i z a t i on  in  the  form  of  supproceou res 
and  pa r ame t e r i zed  structures.  Thus,  macros  are  provided. 
Sequencing  is  series-oarallel  in  straight  text.  IF..THFN,,fcl^E 
and  OFCODE  are  provided  for  control  flow  selection.  Gecurs’on  is 
the  only  iteration  construct  available,  SIGnAL-w&IT  synchroniz*- 
t i on  is  provided.  Timing  is  virtually  ignored  in  that  one  can--' 
Specify  the  time  reouirempnts  of  processes  and  the  only  sv'r 
izatirn  possible  is  through  the  series-parallel  leiut"  ■ '  ;  * 

explicit  synchronization  through  SIGNAL  «no  h  A  I  T  .  r •  - 
data  are  itent  ser«r»  .«  excert  that  control  ■'triiKM  ~  *  •  * 

on  data  through  IF  . . ,  Thf  n  . . .  El  SF  , . .  ano  EtCO01!  c'-t1  - 
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APDL 


APDL  provides  process  modularization  through  procedure*  end 
function*.  IP . .THEN. .ELSE  is  suoported  **  *  sequencing  con¬ 
struct.  So  ere  GOTO  end  IF  EVER*  which  is  similar  to  the  ON  CON¬ 
DITION  of  PL/1.  Another  eid  to  decribing  sequencing  is  the  time 
block.  The  stetements  inside  e  time  block  ere  executed  in  paral- 
lei.  The  time  blocks  mey  not  contein  time  blocks.  Time  require¬ 
ments  for  time  bloeks  mey  be  specified.  The  detc  type  SWITCH 
from  ALGOL  is  avai labia*  and  mey  hold  an  array  of  labels  as  va¬ 
lues.  It  can  then  be  usee  to  facilitate  a  sequence  selection. 


LALSO 

Structural  moaul eri zet i on  is  supported  bv  UNIT*  and  FUNC- 
TIONs.  UNITS  describe  related  structures  and  control  processes* 
while  FUNCTION*  describe  combinatorial  networks  used  within  a 
UNIT.  UNITS  may  be  nestea.  Statements  in  a  UNIT  may  use  objects 
defined  in  an  outer  unit  through  use  of  an  import  speci f icetion. 
Sequencing  constructs  similar  to  IF..THEN..ELSE*  CASE*  and 
FORK, .JOIN  ere  provided.  Iteration  on  a  condition  can  be  speci¬ 
fied.  It  is  possible  to  wait  on  e  condition  or  have  execution  of 
a  UNIT  be  dependent  on  the  setting  of  some  control  variables. 
Control  and  data  are  verv  strictly  separated*  though  control  de¬ 
cisions  may  be  based  on  data  values.  It  is  possible  to  specify 
one  or  more  clocks#  which  mey  be  independent  or  synchronized  with 
other  clocks. 
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SHITE 


SMITE  provides  for  aubprocedure*  through  PROCESSee, 
IP<<THEK<<ELSE  and  CASE  are  provided  for  seauenee  selection. 
Iteration  on  «  condition  and  for  a  count  are  Provided.  A  on  FO¬ 
REVER  construct  is  provided#  and  a  loop  ESCAPE,  PARALLEL-riFGIK 
and  PARALLEL-END  are  provided  to  support  series-parallel  sequenc¬ 
ing.  The  tine  requirement  for  any  simple  or  composite  operation 
eav  be  specified.  Control  and  data  are  carefully  separated#  but 
control  decieions  may  be  based  on  data  values. 


LCD 

LCD  supports  subproeedurea .  It  has  block  structure  scope 
rules.  IF. , THEN. .ELSE  is  provided  for  sequence  selection  and 
NHILE  ia  provided  for  procedural  iteration.  One  Implicit#  dis¬ 
crete  clock  is  assumed.  Relative  timings  of  events  may  be  speci¬ 
fied  based  on  this  clock.  These  timings  can  override  lexical 
order  in  specifying  sequence.  Control  and  data  are  kept  separ¬ 
ate. 


Generality#  Readability  and  hritability 

The  languages  are  now  compared  on  the  basis  of  their  gener¬ 
ality#  readability  and  writability.  These  eherec ter i st i cs  are 
similar  to  those  diseusseo  by  darbecci  toar751 .  The  main  oointe 
affecting  generality  that  are  examinee  are  assumptions  about  the 
machines  being  described#  whether  the  language  can  work  on  dif- 
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new  operators  or  new  attributes  for  module*  and  register*. 
Furthermore,  information  required  by  special  automated  uses  of  an 
ISP  description  may  be  put  into  comments.  ISP  descriptions  have 
been  translated  into  low  level  computer  fabrication  instructions 
and  part*  Hats.  They  have  been  the  basis  of  automated  software 
generation  and  simulations.  ISP  has  also  been  used  for  classroom 
design  efforts. 

ISP  is  highly  readable  and  writable,  since,  after  all.  it 
was  originally  developed  for  exposition.  Its  structures  and  op* 
orators  are  largely  based  on  ALGOL.  One  indication  of  its  sim* 
plicity  is  the  small  size  (6-B  pages)  of  its  own  BNF  grammar  des- 
criptlon.  It  is  therefore  simple  and  familiar.  Its  general  mo* 
dularization  supoort  and  support  of  vectors  and  matrices  of  bits 
allow  a  description  to  closely  follow  the  structure  of  the  des¬ 
cribed  machine.  This  fidelity  is  also  enhanced  by  the  ability  to 
share  resources  between  modules  and  specify  explicit  synchroniza¬ 
tion  and  series-paral 1*1  sequencing. 


APDL 

APDL  makes  no  explicit  assumptions  about  the  machines  it 
describes.  It  ean  be  used  on  an  ISP  as  well  as  a  register 
transfer  level.  It  is  extensible  throuqh  new  operetor*.  It  has 
been  used  for  simulation  and  to  generate  detailed  hardware  des¬ 
criptions.  No  data  has  been  found  on  what  devices  have  been  des¬ 
cribed  in  APDL* 

APDL  closely  resembles  ALGOL  and  has  most  of  the  simplicity 
and  familiarity  of  that  language.  Its  general  medul ar i zat i on  ca- 
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pebIHty  should  sIIom  clots  fidelity  between  a  description  end 


the  described  Machine* 


l  ALSO 

In  LALSD  a  digital  system  eonsiete  of  e  collection  of  units 
uhoss  operation  is  controlled  through  explicit  control  signets* 
Each  unit  in  turn  hes  the  ability  to  generate  sequences  of  con* 
trot  signals  to  operate  its  subcomponents*  The  language  can  only 
work  at  the  register  transfer  level*  It  is  extensible  through 
the  addition  of  new  operators*  It  has  been  used  for  simulation 
and  logic  description  generation* 

LALSD  is  a  rather  complex  language  requiring  all  descrip* 
tions  to  have  a  fairly  complex  structure*  It  would  have  a  herd 
time  describing  with  much  fidelity  a  machine  that  was  not  a  sys* 
tern  of  cooperating  units*  such  as  a  -machine  implemented  through 
micro-programming*  where  the  complexity  lies  in  the  stored  con* 
trol  program  more  than  in  the  hardware*  While  LALSD  provides  e 
lot  of  familiar  and  useful  facilities*  it  uses  unfamilier  con* 
structe  to  support  them*  For  instance*  "/  condition  /"  means 
"wait  on  condition"  and  "  (A]  ->  8"  means  "IF  A  THEN  B", 


SMITE 

SHITE  is  only  useful  St  a  register  transfer  level  of  dee* 
criotion*  It  makes  no  restrictive  assumptions  about  the  machines 
it  describes*  It  is  extsnsibile  through  the  addition  of  opera* 
tors*  8MITE  is  used  for  writing  emulators  for  the  OM»i, 


* 


/: 
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( 
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The  language  4a  simple*  and  uses  familiar  constructs.  Its 
modularisation  capabilities  should  allow  a  description  to  closely 
follow  the  structure  of  the  described  machine. 

LCD 

LCD  assumes  that  the  operations  in  a  described  machine  take 
place  in  discrete  steps  in  time  with  a  single  system  clock.  It 
is  useful  at  the  register  transfer  level  only.  It  can  he  extend* 
ed  through  introducing  new  operators.  LCD  is  being  used  for  de¬ 
sign  and  simulation. 

The  language  uses  familiar  constructs  and  allows  for  simple 
descriptions  except  for  the  reouirement  for  redundeney.  The  re¬ 
dundancy  may  aid  understand! no  of  the  description  and  automated 
consistency  checking.  The  modul ari cat  ion  capabilities  of  the 
language  should  allow  the  structure  of  a  description  to  closely 
follow  the  structure  of  the  described  machine. 

Summary 

It  can  be  seen  that  there  is  a  great  deal  of  similarity 
among  the  various  procedural  languages*  especially  in  the  facili¬ 
ties  they  provide.  Puposes  very*  but  most  ere  oriented  toward 
describing  the  behavior  of  e  system  at  any  lavel  of  detail  using 
RT  primitives.  Data  objects  supported  ere  similar  among  the 
languages*  with  bits  and  integers  being  provided  along  with  vac* 
tore  end  matrices  of  hits.  Integers  are  assumed  to  be  veetore  of 


bit* 


While  only  SHITE  provides  for  abstract  format  specifica¬ 
tion*,  most  languages  allow  the  renaming  of  fields  of  specific 
vectors  for  ease  of  access*  Indexing  Is  always  supported,  but 
sometimes  restricted  to  use  with  explicit  address  registers  or 
simple  expressions*  Arithmetic,  boolean,  end  relational  opera¬ 
tors  are  generally  provided  along  with  concatenation  and  shift 
operators*  AH  of  these  operators  are  available  for  use  in  arbi¬ 
trarily  complex  expressions*  Registers  and  terminals  are  usually 
provided  as  date  carriers  along  with  transfer  and  connection  as- 
sigments*  Some  concept  similar  to  subprocedures  and  functions  is 
usually  provided  for  modu 1 ar i zat 1  on,  though  the  form  of  the  con¬ 
trol  constructs  and  their  exact  semantics  do  very.  Host  of  the 
1 anguages. are  rather  easy  to  write  and  understand,  since  they  all 
(to  some  degree)  are  simple,  use  familiar  constructs,  and  provide 
e  fair  degree  of  fidelity  to  the  described  hardware.  Also,  a 
wide  variety  of  control  constructs  are  provided.  However, 
IF.*THEN..ELSE*.,  or  something  analogous,  is  the  only  construct 
always  provided.  Generality  and  treatment  of  time  vary  widely 
among  languages* 

ISP,  with  its  unique  emphasis  on  exoosition,  is  the  most 
general  of  the  procedural  languages  and  is  the  most  extensible, 
as  well.  Its  series-paral 1  el  sequencing  and  signal-wait  syn¬ 
chronization  primitives  are  very  high  level,  lacking  the  ability 
to  precisely  describe  fine  timings, 

APDL  is  unique  in  belnq  mainly  concerned  with  seec 1 f 1  cat  1  on 
of  a  system  without  attention  to  design  details*  In  support  of 
this,  APDL.  Provides  th*  widest  variety  of  data  types,  including 
state  encodings  (called  switches),  which  are  not  supported  by  any 
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other  procedural  languages*  In  add! t 1 on#  rAPDL  la  the  only  Broca* 
dural  1 anguaoa  to  hava  a  GOTO  or  an  Interrupt  handling  primitive 
(IF  EVER,*,).  Its  time  block#  which  allow  for  some  Parallelism 
and  timing  specification#  is  unusual#  also, 

LALSO  is  the  only  structurally  oriented  procedural  languaoe 
and  is  also#  approori atel y#  the  only  procedural  language  to  fea* 
ture  a  connection  assignment,  LALSD  is  a  lower  level  language 
than  the  other  procedural  languages#  as  exemplified  by  its  reli* 
ance  on  met  ronome-1  i  ke  decks  and  the  requirement  for  an  explicit 
address  register.  One  interesting  aspect  of  LALSD  is  its  use  of 
controlled  scopes.  Otherwise#  however#  it  is  less  easy  to  use 
than  the  other  languages  Cue  to  its  complexity  and  its  use  of  un¬ 
familiar  constructs, 

SmITF  is  the  only  language  designed  for  emulation. 
Otherwise  it  is  distinguished  by  its  wide  variety  of  useful  and 

a 

familiar  control  constructs  and  its  ability  to  precisely  describe 
timing  requirements, 

LCD  is  the  only  language  to  allow  for  redundant  descrio* 
tions.  It  also  allows  for  precise  description  of  timing. 


Nonprocedural  languages 


Tha  languages  described  in  this  section  ere  CDL  tChufeS) ,  001 
10068),  HOP  CCat7?) ,  Cassandra  IBGL71),  ERES  16HH77) ,  end  AHPL 
CHR73) ,  (H‘il75I.  The  organization  of  the  discussion  in  this 
chapter  will  be  similar  to  that  of  the  second  chapter* 
Character) at  ice  of  the  languages  will  be  grouped  in  the  same  way 
with  the  languages  being  compered  on  the  basis  of  each  grouo  in 
turn.  The  definition  of  terms  and  discussion  of  issues  will  not 
be  repeated.  The  reader  is  left  to  go  to  the  second  chapter  for 
this  material. 


Purpose,  Description  Type,  and  Level  of  Description 


CDL 

CDL  was  developed  for  use  with  digital  design  and  simula¬ 
tion,  Descriptions  in  CDL  specify  a  verv  detailed  implementa¬ 
tion,  These  descriptions  ere  oriented  toward  the  behavior  of  a 
system  rather  than  its  structure,  CDL  primitives  ere  on  the  re¬ 
gister  transfer  level.  Redundant  descriptions  are  not  allowed* 


i 

DDL 

DDL  was  developed  for  digital  design.  It  ean  be  used  for  a 
wide  range  of  levels  of  detail.  The  descriptions  are  oriented 
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toward  the  behavior  of  a  system.  DDL  primitives  are  at  the  re* 


gister  transfer  level  of  description.  Redundant  descriptions  are 
not  al 1  owed. 


MOP  was  Intended  for  use  with  the  automatic  generation  of 
software.  It  is  oriented  toward  the  behavior  of  machines  and  the 
descriptions  written  in  muP  are  high  level  specifications, 
Redundant  descriptions  ere  not  allowed,  mop's  primitives  are 
atrictly  on  tha  ISP  level  of  description. 


Caisandre 

Cassandra's  purpose  was  to  aid  design  and  development  of 
digital  systems.  Cassandre  is  oriented  toward  describing  the  be* 
havior  of  a  system  more  than  its  structure.  Descriptions  in  r as* 
sandre  can  be  at  any  level  of  detail  from  a  high  level  specifics* 
tion  to  a  detailed  i mp 1 ementat i on.  Cassandra  primitives  are  at 
tha  re g ieter  transfer  level  of  description.  There  is  no  al* 
lowanee  for  redundant  descriptions. 


fcPES 


ERES  was  designed  for  use  in  computer  hardware  design.  ERES 


is  oriented  toward  descririnq  the  structure  of  a  computer,  and 
can  oe  used  for  descriptions  over  a  wide  ranqe  of  levels  of  deta* 
il.  Redundant  descriptions  are  not  allowed.  EPfcS  can  be  used  at 
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the  register  transfer  or  switching  circuit  level  of  description 


AHPL 

AHPL  mii  developed  for  use  In  teaching  design.  Descriptions 
in  AHPL  are  non-redundant  and  are  oriented  toward  the  behavior  nf 
a  svatem,  AmPL  Is  appropriate  for  writinq  specifications  and  can 
be  used  to  describe  a  fairly  detailed  specification.  The 
language  is  mainly  useful  on  the  register  transfer  level  of  des¬ 
cription,  though  it  can  be  used  to  do  some  description  on  the 
switching  circuit  level. 


Data,  Carriers*  and  Assignments 


CDL 

CDL  suoports  oits  and  integers  In  the  described  machine. 
Vectors  of  bits  may  oe  defined,  Memories,  arrays  of  register 
vectors,  mev  be  defined  with  an  explicit  address  register  for  in¬ 
dexing.  Vectors  of  bits  may  be  treated  as  integers.  Pegister 
subfields  end  collections  of  registers  mev  be  given  names  for 
ease  of  reference.  Addition,  subtraction,  i nc rement at i on  end  de¬ 
crementation  are  defined  for  integers.  The  logical  operators 
AnO,  OP,  NOT,  and  EQUIVALENCE  are  provided.  A  full  set  of  shift 
and  relational  operators  are  provided,  a  concetenet i on  operator 
is  Provided,  In  addtion,  FETCH  eng  STOHF  are  provided  for  memo¬ 
ries,  Since  COL  operations  are  tupDOsed  to  be  done  in  e  single 
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clock  ptriodt  expressions  must  he  kept  simple. 

Register  end  terminal  carriers  are  provided#  along  with  sep¬ 
arate  transfer  and  connection  assionments.  The  connection  as¬ 
signment  symbol  can  be  useo  to  represent  multiplexing  or  renam¬ 
ing,  A  distinct  exchange  operator  is  provided  for  swapping  the 
values  stored  in  two  registers. 


DDL 

The  only  data  type  provided  by  DDL  for  th«  described  machine 
is  bits#  and  integers  are  provided  as  compile-time  bookkeeping 
variables.  Arrays  of  bits  may  be  defined  with  an  arbitrary 
number  of  dimensions  and  arbitrary  index  bounds.  Index  formation 
rules  ere  those  o*  ISP  (see  Sec  2.2.}).  Subfields  of  arrays  and 
collections  of  registers  may  be  renamed  as  single  arrays.  The 
logical  ooerators  AND#  NAKO,  NOR#  eouivalence#  OR#  and  exclusive 
or  are  provided,  Additicn,  subtraction  and  the  usual  relational 
operators  efe  provided  alcnq  with  concatenation#  complementation# 
selective  complementation#  and  reduction  for  vectors. 
Arbitrarily  complex  expressions  may  be  formed.  Register  and  ter¬ 
minal  carriers  are  provided.  Connection#  transfer#  renaming,  and 
bookkeeping  assignments  are  supported. 


MOP 

ROP  assumes  that  carriers  in  a  machine  are  composed  of  bits 
and  it  support  s  any  data  type  encoded  in  a  vector  of  bits. 
Vectors  and  matrices  of  bits  are  supported  and  strong  format 
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spec i f 1  cat  1  on  tools  are  provided.  Rows  of  matrices  may  be  ••• 
lecteH  through  Indexing  #no  fields  of  a  row  may  be  specified* 
Any  exoresslon*  Including  an  Indexed  value  may  be  used  as  art 
Index.  These  accessing  primitives  may  be  used  to  define  new  ac- 
cess  modes  that  can  then  be  used  by  other  parts  of  the  descrip* 
tlon.  Normal  programming  language  data  operators  are  available 
along  with  common  machine  language  operations.  These  operators 
may  be  combined  to  form  arbitrarily  complex  expressions.  MOP 
only  allows  for  register  carriers  and  transfer  assignments. 


Cassandra 

Cassendre  supports  Integers  and  hits  which  may  be  composed 
Into  vectors  and  matrices.  Bookkeeping  Integers  are  also  provld- 
ed.  Constants  and  ranges  of  constsnts  may  he  used  as  Indexes* 
The  result  of  a  decode  operator*  whose  operand  Is  a  bit  vector# 
may  be  used  as  an  Index  when  a  data  value  needs  to  be  used  as  an 
Index,  The  following  operations  are  provided:  AND*  OR#  equiva¬ 
lence#  exclusive  or#  reduction  of  a  vector  by  these  first  four# 
concatenation#  negation  and  the  previously  mentioned  decode  oper¬ 
ator.  Arbitrarily  complex  expressions  may  he  formed  using  theaa 
operators#  except  the  decode  operator.  If  the  decode  operator  Is 
used  in  an  expression#  the  expression  must  Involve  only  a  direct 
connection  or  transfer  of  the  indexed  value. 

Register  and  terminal  carriers  art  provided.  A  connection 
assignment  Is  provided  for  terminals  and  a  distinct  transfer  as¬ 
signment  symbol  is  provided  for  transfers.  Transfers  must  bs 
controlled  by  a  clock  signal.  A  bookkeeping  assignment  Is  pro- 
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vided  for  the  bookkeeping  integers. 

ERES 

ERES  supports  bits  as  its  primitive  data  tvpe.  Bits  can  he 
composed  into  vectors  eno  matrices.  If  variable  expressions  are 
to  be  used  as  an  index  for  a  row  of  a  matrix,  an  explicit  address 
register  must  be  specified.  Groups  of  arrays  and  bits,  subsets 
of  arrays,  and  groups  of  subsets  may  be  renamed  to  facilitate 
multiple  views  and  accessing  methods  for  structures.  &N0,  OR. 
NOT.  addition,  and  i nc rement at i on  are  provided  as  primitive  oner* 
at  ions.  as  well  as  others.  Any  vector  mav  he  interpreted  as  an 
integer  for  arithmetic  purposes.  Arbitrarily  complex  expressions 
may  be  formed. 

Terminals  and  registers  are  supported  as  carriers,  with  con* 

4 

nection  and  transfer  assignments  being  provideo.  Multiplexing  is 
assumed  if  multiple  connections  are  specified  to  the  same  termi¬ 
nal.  Renaming  is  expressed  with  an  assignment  statement. 

AHPL 

AHPL  provides  for  operations  on  bits  and  integers.  The  in¬ 
teger  operations  operate  on  vectors  of  bits.  Support  is  provided 
for  vectors  snd  mstricss  of  bits  with  the  rows  of  the  matrices 
being  accessed  only  through  constant  indices  or  an  explicit  in¬ 
dexing  operator,  while  columns  m»y  only  be  accessed  through  con¬ 
stant  indices.  It  should  be  noted  that  bookkeeping  inteqers  are 
provided  at  compile  time  which  may  be  used  in  piece  of  constant 
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indices.  There  are  no  format  description  tools  provided,  ahpl 
provides  the  standard  arithmetic#  boolean#  relational#  and  shift 
operators#  as  well  ss  absolute  value#  maximum#  minimum#  eoncate- 
nation#  decode#  encode#  reduce  and  compress  operators.  A  func¬ 
tion,  syn,  is  provided  for  detecting  signals  from  asynchronous 
systems.  It  is  true  if  its  argument#  a  signal#  was  reeieved 
since  the  last  clock  signal.  Expressions  not  involving  the  in-  | 

dexing  operator  resemble  those  of  APL.  The  expressions  may  be-  j 

come  aroitrarily  complex  except  that  one  would  went  to  limit  the 
operators  and  the  complexity  of  expressions  for  more  detailed 
descriptions.  The  indexing  operator  may  only  be  used  where  the  1 

index  is  held  in  a  simple  register  (bit  vector)  and  the  indexed 
value  is  directly  connected  or  transfered  to  a  terminal  or  regis¬ 
ter,  respectively. 

ahpl  provides  a  variety  of  carriers  and  assignments.  The 
carriers  include  inout  terminals#  output  terminals#  registers# 
busses#  ONE  SHOTs#  and  bookkeeping  variables.  Assignments  can  bs 
used  to  describe  multiplexed  or  permanent  connection  to  the  ter¬ 
minals  and  busses.  ONE  SHOTs  have  some  default  value  which  will 
change  for  some  period  after  being  set  to  the  non-default  vali'a. 

The  delay  time  (the  amount  of  time  th*  device  maintains  ‘he 
non-aefault  value)  is  specified  in  the  ONE  SHOT’S  declaration. 

Assignment  is  used  for  the  transfers  to  registers  and  ONE  SHOTs# 

and  for  setting  and  changing  the  value  of  bookkeeping  variables.  ^ 

( 
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Modul er 1 z at  1  on.  Control  and  Data*  and  Tima 


COL 

In  CDL*  one  may  perform  tome  structural  modularization 
through  defining  combi nator 1 al  networke.  Sequences  of  actlona 
may  be  defined*  facilitating  procedural  modularization.  Both  of 
these  definitions  are  available  throughout  the  description  In 
which  they  appear.  A  00  construct  Is  provided  to  envoke  prede¬ 
fined  action  sequences  ano  an  IF » . THEN. .ELSE  Is  provided  for  pro¬ 
cedural  selection  (choosing  between  alternative  actions). 
Activation  conditions  are  used  to  control  actions.  All  the  ac¬ 
tions  associated  with  an  activation  condition  are  performed  In 
parallel  when  the  condition  is  true.  A  single  clock  may  be  de¬ 
clared  and  Is  required.  It  la  used  to  describe  a  machine's  beha¬ 
vior  with  respect  to  time.  Control  and  data  are  separately  iden¬ 
tified  with  IF ., Then, .ELSE  and  the  activation  conditions  allowing 
control  functiona  to  be  affected  by  data. 

DDL 

DDL  provides  for  structural  modularization  through  defini¬ 
tion  of  combi nator i al  networks  end  declaration  of  ELEMENTS#  spe¬ 
cial  units  with  unspecified  structure  and  behavior.  These  spe¬ 
cial  units  may  be  usee  to  suppress  detail,  objects  declared 
within  a  module  are  only  accessible  within  that  module. 

Boolean  networks  are  declared  with  a  BO  statement. 
Combinatorial  networks  (related  blocks  of  terminals  end  boolean 


network*)  m*y  be  declares  using  OP  statements.  An  EL  statement 
define*  the  input  end  output  ports  of  e  component  without  defin- 
ing  its  behevoir  or  internal  structure*  The  component  is  avail* 
able  for  use  within  the  module  where  the  component  is  declared* 

There  are  three  levels  of  modules  in  a  DDL  description*  The 
top  level#  celled  e  system#  corresponds  to  the  entire  described 
machine.  The  system  is  divided  into  automatons  and  the  automa¬ 
tons  are  subdivided  into  segments#  with  segments  being  optional* 
Only  the  bottommost  level  may  have  action  statements*  Note  that 
this  outs  a  low  limit  on  the  amount  of  nesting  possible  in  a  bas¬ 
er  i  ot  ion. 

Structural  iteration  is  possible  and  is  aided  by  a  compile 
time  control  variable.  Procedural  constructs  analogous  to 
IP ,. THEN, .ELSE  and  CASE  are  provided  for  procedural  selection.  A 
macro  facility  is  provideo  by  the  ID  statement#  though  parameters 
are  not  supoorted. 

Sequencing  is  controlled  through  states.  Only  one  state  of 
an  automaton  may  be  active  at  any  one  time.  The  actions  for  a 
given  state  are  performed  in  parallel  and  listed  together  with  a 
label  for  the  state,  a  condition  may  be  specified  for  a  state  so 
that  if  an  automaton  reaches  that  state#  the  actions  for  the 
state  will  not  be  performed  until  th*  condition  is  satisfied. 
State  changes  are  explicit  operations.  The  state  may  be  encoded 
in  a  memory  end  th*  register  specifying  the  current  state  may  be 
given  a  name.  State  changes  between  segments  of  an  automaton 
specify  a  default  return  state  within  the  current  seqment.  Thus# 
among  other  things#  an  operation  may  treat  a  segment  as  a  subpro¬ 
cedure  by  specifying  the  current  state  as  the  return  state.  It 


is  possible  to  specify  a  condition  for  any  1,evel  module,  The  sc- 
tlons  of  that  module  will  be  held  up  until  the  condition  becomes 
true*  It  Is  possible  to  specify  a  set  of  actions  for  en  automa¬ 
ton  or  segment.  These  operations  will  be  performed  In  eaeh  state 
of  the  automaton  or  segment*  respectively. 

Delays  ana  single  or  multiele  clocks  may  be  specified  to 
allow  description  of  the  behavior  of  the  described  oevlce  with 
respect  to  time. 


HOP 

There  Is  only  one  modularisation  concept  in  mop  in  the  sense 
of  grouping  of  functions  or  structures  under  a  name.  This  con¬ 
cept  la  the  Operand  Class*  which  defines  e  set  of  addressing 
methods  for  easy  reference.  Since  Operand  Classes  may  overlap* 
they  are  a  kind  of  macro  facility.  However*  the  lenguaae  does 
provide  for  (force*  really)  a  petitioning  of  the  conceptualisa¬ 
tion  of  a  computer.  The  1 nterpret at  1  on  cycle.  memories*  data 
types*  addressing  modes*  operand  classes  (discussed  above)*  in¬ 
struction  fields*  Instruction  formats  and  instruction  behavior 
are  each  treated  seoaretely. 

HUP  assumes  an  Implicit  1 nterpretst 1  on  cycle  which  controls 
which  of  the  described  instructions  Is  oerforwed  at  any  given 
time.  Because  of  this  and  the  fact  that  mop  deerlbes  very  high 
level  behavior*  the  motivation  for  control  contructs  is  low.  The 
main  control  construct  Is  analogous  to  IF ,. THEN. .ELSE  and  is  used 
in  describing  Instruction  actions. 
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Behavior  with  respect  to  time  is  described  through  specify* 
ing  a  time  cost  for  each  instruction.  Control  and  date  era  kept 
separated  except  that  decisions  about  actions*  including  program 
counter  modification*  may  bo  based  on  data  values. 

Cassandra 

Cassandre  allows  a  system  to  be  decomposed  into  units. 
Units  may  be  nested  and  may  be  connected  arbitrarily.  Thia  al* 
lows  the  deecription  of  any  system  of  interrelationships.  One 
can  also  define  sequences  of  actions  that  can  be  invoked  from 
several  daces  in  a  unit. 

One  may  specify  that  multiple  units  within  a  given  unit  may 
be  active.  Pulses  may  be  transmitted  between  units  for  synchron¬ 
ization  and  communication.  Clocks  may  also  be  used  for  timing 
and  synchrod  *at  i  on, 

Each  action  statement  is  either  labeled  with  a  state  or  is 
part  of  a  labeled  group  of  statements.  Only  one  stete  of  a  unit 
is  active  at  any  one  time  and  transfers  between  states  are  expli- 
cit.  States  may  be  encoded  in  registers.  IF. .THEN, .ELSE  is  pro¬ 
vided  for  procedural  selection.  Structural  iteration  is  orovided 
for  parallel  execution, 

E*ES 

FRES  provides  for  definition  of  action  sequences  and  Boolean 
networks  as  aids  for  modul ar i zat i on.  Actions  and  groups  of  ac¬ 
tions  are  controlled  by  ectiyiation  conditions.  IF. , THEN, .ELSE 
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is  provided  for  procedural  selection, 

ERES  allows  specification  of  the  time  required  for  simple 
and  composite  actions.  All  transfers  are  dependent  on  clock 
pulses*  In  an  extended  version,  multiple,  possibly  asynchronous, 
clocks  may  be  specified  ana  primitives  ere  provided  for  coordine- 
tion  of  asynchronous  parts  of  the  system.  The  basic  version  of 
ERES  allows  for  a  single  clock  for  the  system, 

AHPL 

The  modul ar i zat i on  constructs  nrovioeo  by  AHPL  support  the 
definition  of  undeseribed  components  end  combinatorial  networks. 
These  networks  are  low  level  modules  involvino  simple  date  opera* 
Cions  and  no  iteration,  though  they  can  describe  rather  complex 
patterns  of  connection.  An  AHPL  statement  consists  of  actions 
together  with  branches  for  deciding  the  state  t ransi st i ons.  The 
actions  can  be  any  mixture  of  connections  and  transfers,  which 
are  assumed  to  operate  in  parallel.  The  target  of  a  transfer  can 
be  made  dependent  on  data  and  transfers  can  be  conditional.  Each 
statament  is  numbered  and  corresponds  to  a  state,  and  the 
branches  refer  to  the  statement  numbers.  Ampl  provides  the  APL 
operators  for  branching  and  selection.  Thev  provide  the  normal 
Capabilities,  but  special  characters  are  used  to  represent  them 
rather  than  key  words.  Structural  iteration  is  provided,  includ¬ 
ing  bookkeeping  variables.  It  is  possible  to  specify  that  a  pro¬ 
cess  wait  or  not  wait  for  the  completion  of  an  initiated  opera¬ 
tion,  Control  and  data  are  separately  identified  and  selection 
is  provided  to  allow  control  deesions  to  deoena  on  data. 


DIVERGE  end  CONVERGE#  which  are  similar  to  fork  and  join# 
allow  for  th«  description  of  parallel  processes#  In  addition# 
ONE  SHOTS#  syn#  and  delays  can  all  be  used  to  describe  timing. 


Generality#  Readability  and  writability 


CDL 

CDl's  main  assumption  about  a  device  is  that  it  has  only  one 
clock.  Descriptions  in  CDL  are  confined  to  a  primitive  register 
transfer  level.  COL  can  be  extended  through  new  operators. 

Though  comments  are  supported#  CDL's  lack  of  modul ar i zat i on 
tools  greatly  restricts  readability  and  writability.  Since  a 
description  is  strictly  linear#  it  cannot  follow  the  structure  of 
the  described  machine#  Also#  because  the  of  the  global  scope  of 
any  identifier#  large  descriptions  are  going  to  start  having 
problems  with  name  conflicts#  especially  if  more  than  one  person 
is  working  on  the  same  descriotion.  It  also  becomes  difficult 
for  a  human  to  spot  cooperating  parts  of  the  machine  and  shared 
facilities#  The  language  is  simple#  however#  and  uses  familiar 
notations  for  standard  concepts# 


DDL 

DDL  makes  no  substansive  assumptions  about  devices  being 
described#  Descriptions  can  be  at  the  register  transfer  level  or 
switching  circuit  level.  The  language  is  extensible  through  new 
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operators  and  predefined  elements  (undetcMhed  components) 


DDL  h#s  been  used  for  design#  documentation#  simulation  ana 
logic  design  automation.  It  nes  been  used  to  describe  a  variety 
of  machines  designed  for  classroom  exercises  and  research. 

The  language  Is  rather  simple#  using  many  familiar  con* 
structs.  However#  the  procedural  selection  notations  are  non¬ 
standard  and  nor  suggestive.  The  limited  depth  of  modularization 
could  hamper  fidelity  and  readability.  Clusters  of  closely  coo¬ 
perating  automatons  are  hard  to  represent  and  may  be  hard  for  the 
reader  to  spot.  Also#  modules  that  are  subcomponents  of  other 
modules  may  be  very  hard  or  impossible  to  represent#  again  limit¬ 
ing  fidelity. 


MOP 

MOP  assumes  a  device  has  memories  emooavfng  the  machine 
state#  Instructions  to  change  the  state#  a  main  memory  to  hold 
the  instructions#  end  an  Instruction  interpretation  cycle  with  a 
program  counter.  It  Is  thus  limited  to  describina  machines  which 
perform  one  high  level  operation  at  a  time  in  reponse  to  stored 
data.  Thouah  parallel  operations  may  be  used  to  implement  an  in¬ 
struction#  they  cannot  be  described  with  mop.  wOP  can  be  extend¬ 
ed  through  introduction  of  new  constructs  to  describe  the  actions 
of  the  Instructions.  MOP  is  limited  to  ISP  level  descriptions. 
It  has  been  used  to  describe  the  POPS  and  pop11/?0  for  code  aen- 
eretor  derivation  purposes. 

One  interesting  aspect  of  MOP  is  that  a  MOP  description  of  a 
computer  mav  be  derived#  with  little  human  inout#  from  a  descrip- 
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op¬ 
tion  written  in  ISP*  which  is  helpful  in  light  to  the  impediments 
to  wide  epplicability  of  HOP,  This  method  has  been  used  to  gen- 
erate  a  HOP  description  of  the  PDPil/70. 


Cassandra 

Cassandra  assumes  that  a  computer  consists  a  collection  of 
potentially  nested  automata*  each  of  whose  operation  is  eon- 
trolled  by  discrete  states  with  state  transitions  oecuring  at 
clock  signals.  Actions  for  a  given  state  are  performed  in  a  sin* 
gle  clock  period.  Inscriptions  are  confined  to  the  register 
transfer  level  and  e*t ansi bi 1 i ty  is  hard  to  assess  from  available 
descriptions  (the  main  language  definition  is  a  Ph.D, 
dissertation  written  in  French),  Cassandra  has  been  used  to  des- 
cribe  a  16-bit  ALGOL  machine  and  a  system  having  two  linked  INTEL 
8080's.  Automated  applications  are  envisioned  which  will  reduce 
Cessendre  descriptions  to  lower  level  descriptions*  estimate  the 
cost  of  units*  analyze  descriptions*  support  description  modifi¬ 
cation*  do  reliability  analysis*  design  circuit  test  procedures* 
produce  graphical  representations  of  a  system*  and  aid  the  design 
of  mi c ropnogremmed  machines. 


ERES  , 

ErtES  as  currently  defined  assumes  synchronous  systems  that  < 

are  composed  of  synchronous  seouential  networks  and  combinatorial 
networks.  A  proposed  extension  (GJK)  provides  mechanisms  for  co¬ 
operation  between  asynchronous  parts  of  a  system.  The  1 anguage 
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can  be  uaea  on  the  register  transfer  level  or  the  twitching  cir 
coit  level*  anrl  is  extensible  through  introduction  of  new  opera 


tors*  Information  is  not  available  on  what  applications  have 
been  developed  usinq  FRFS  nor  on  th«  machines  that  have  been  dea- 
cribed  in  E&ES. 

The  language  is  synt sc t i eal 1 v  simple  end  uses  familar  con¬ 
structs*  The  modul ar i zat i on  tools  seem  rather  weak*  particularly 
if  one  wishes  to  describe  a  hierarchy.  This  will  hurt  both  the 
clarity  of  descriptions  arc  their  fidelity. 


AHPL 

AHPL  can  describe  register  transfer  and  awitchino  circuit 
level  operations*  and  provides  a  completely  general  parallelism 
construct*  However#  the  weakness  of  the  modularization  con¬ 
structs  will  auickly  become  more  end  more  of  a  problem  as  the 
8i*e  of  a  description  grows.  This  combined  with  its  provision  of 
high-level  operators*  makes  the  languaqe  mainly  useful  for  beha¬ 
vioral  system  specifications*  The  language  is  simple*  but  uses 
special  characters  which  may  not  be  suggestive  or  familiar  to 
uteri,  Also*  because  of  the  oroblems  with  modularization  cited 
above*  AHPL  descriptions  will  have  a  hard  time  retaining  fidelity 
if  they  go  below  the  level  of  a  specification. 
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Summary 


These  non-procedure  1  lanquaqes  are  rather  similar  to  each 
other,  except  ♦or  the  rather  distinctive  character  1 st  i  ea  of  MOP. 
most  of  the  languages  were  developed  for  design,  end  oriented  to- 
ward  describing  the  behavior  of  a  system  at  any  level  of  detail, 
using  RT  level  primitives.  Vectors  and  matrices  of  bits  are  gen¬ 
erally  supported  with  vectors  of  bits  being  used  to  hold  in¬ 
tegers.  Except  for  HOP,  no  language  provides  format  description 
tools.  Renaminq  and  some  restricted  form  of  indexing  ere  usually 
provided  to  facilitate  accessing  parts  of  composite  structures, 
most  languages  provide  for  arbitrarily  complex  expressions  with 
addition,  subtraction,  boolean,  relational,  concatenation,  and 
complementation  operations  available  for  use  within  expressions. 
Registers  snd  terminals  are  generally  supported,  along  with 
transfer,  connection  eno  renaming  assignments.  Modularization 
tools  are  usually  limited,  with  combinatorial  networks  being  pro¬ 
vided  for  structural  modularization  end  short  action  seauences 
being  definable  for  procedural  modul ar 1 zat i on.  Control  con¬ 
structs  sre  limited,  but  each  provides  some  facility  for  alterna¬ 
tion.  Host  languages  support  clocks  as  s  tool  for  describing  e 
system's  behavior  with  rssoect  to  time.  The  languages  are  gener¬ 
ally  restricted  to  the  RT  level  or  RT  and  switching  circuit  lev¬ 
els  of  description.  The  lengueaes  ere  usually  simple  end  usually 
provide  familiar  facilities,  weak  modul sr i zat ion  tools,  snd  sre 
limited  in  how  closely  e  description  cen  follow  the  structure  of 
•n  implementation. 
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CDL  Is  cH  st i ngu i shed  b«  Its  generally  low  level#  as  seen  in 


its  requirement  for  simple  express i ons#  and  is  mainly  suitable 
for  an  implementation  level  description,  DDL#  Cassandra#  ana 
AHPL  are  the  only  languages  to  support  structural  iteration  ana 
bookkeeping  variables,  DDL  and  AHPl  are  the  only  languages  to 
provide  for  use  of  undefined  components  an*  they  are  also  unique 
i n  support ing  delays,  DDL  and  Cassanere  are  the  only  lanouagaa 
to  support  state  encodings.  They  also  provide  the  more  powerful 
modul ar i zat i on  tools.  Consistent  with  its  focus  on  the  specifi- 
cation  level#  AHPL  provides  a  rich  array  of  high  level  operator 
and  a  wide  variety  of  carriers,  including  some  that  are  rather 
useful  for  synch roni tat i on  with  other  systems.  It  is  unfortunate 
that  it  uses  such  unfamiliar  synactic  forms  for  its  constructs. 
HOP’S  concern  with  code  generation  anplication  appears  in  #any 
Jays#  including  its  high  level;  lack  of  constraints  on  nata 
types#  accessing  modes  and  operators;  lack  of  terminals;  its 
form  of  modu 1  a r i zat i on >  and  the  insistence  on  time  and  space  re¬ 
quirements  for  instructions. 
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Exclusion* 


This  comparison  was  made  as  a  part  of  a  project  investigate 
i  ng  compiler  retargeting#  and  therefore  mainly  examined  those 
languages  that  would  be  useful  in  a  retargetable  compiler  system, 
Flowware  was  therfore  excluded  from  the  study  since  it  is  based 
on  graphic  input  and  the  retargetable  would  require  textual 
input,  LOCAL#  evidently  very  useful  at  Univae  for  design#  was 
too  low  level  and  lacked  the  extention  capability  necessary  to 
provide  information  needed  for  compilation. 
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Interesting  but  Incomplete  l anguages 


This  section  discusses  two  languages  whieh  are  Intended  tor 
wide  utility  and  ease  of  use.  The  languages  ConLan  ana  RTS  III 
ere  not  yet  complete  end  therefore  cannot  yet  be  exhaustively 
compared  to  the  other  languages  In  the  study* 


ConLan 

Conlan  is  being  developed  by  the  Conference  on  Computer 
Hardware  Description  Languages  and  Is  intended  to  be  suitable  for 
all  CHDL  applications  (Pil77J,  The  group  has  been  working  on 
this  rather  ambitious  task  since  September*  1*>73,  Its  latest  re¬ 
port  was  distributed  In  June  of  197P,  To  try  to  be  useful  for 
all  applications*  Conlan  irust  be  able  to  describe  systems  on  sev¬ 
eral  levels  of  description  and  at  various  levels  of  detail. 

This  breadth  of  levels  Is  belno  attempted  through  definition 
of  a  primitive*  low  level  language*  Primitive  Set  ConLan*  for 
which  some  very  powerful  composition  ano  type  definition  con¬ 
structs  are  defined.  These  composition  and  definition  tools  are 
then  to  be  used  to  define  more  powerful  and  useful  languages. 
One  goal  is  to  standardize  the  definitions  of  these  more  powerful 
languages  In  addition  to  their  being  defined  In  terms  of  the  same 
primitive  language. 

The  ConLan  working  group  has  also  proposed  a  two-tiered  de¬ 
finition  of  time  with  "virtual"  time  steps  within  a  "real"  time 
step.  This  will  hopefully  be  sufficient  for  the  needs  of  eny  ao- 
pl i cat  1  on. 
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The  above  concepts  ere  presently  only  propesets  of  the 
Conference  Working  Group  end  heve  not  been  adopted  by  the  Confer* 
ence  on  CHDL's  «s  e  whole.  Much  work  still  remains  in  completing 
the  primitive  base  and  the  specifying  the  various  application 
languages  based  on  it. 

RTS  III 

RTS  III  is  being  developed  by  Robert  Piloty  and  his  eowork* 
era  in  Darmstadt  CPil75J.  They  are  focusing  on  the  need  for  var¬ 
ious  modularization  tools  in  a  CDL  that  is  to  be  used  in  a  wide 
variety  of  applications  and  in  all  stages  of  design  and  implemen* 
tation  of  a  system.  Current  proposals  ioentify  externally  con¬ 
trolled  modules,  automatons,  open  sequences  ana  combinatorial 
networks.  The  different  designations  allow  some  checking  of  the 
body  of  a  module  to  be  sure  it  has  certain  formal  properties. 
The  constructs  are  quite  general  and  modules  esn  ba  nested  to  any 
depth.  A  powerful  mecro-like  facility  ia  defined  to  facilitate 
the  use  of  similar  components  in  different  parts  of  s  system. 

In  addition  to  the  segmentation  constructs,  the  basic  state¬ 
ment  sytax  and  semantics  have  been  defined.  The  language  I#  be- 
aicly  non-procedural ,  with  event  conditions  controlling  groups  of 
actions.  There  is  also  an  allowance  for  procedural  descriptions* 
Registers  and  tarminals  are  supported  and  can  ba  declared  aa 
input,  outnut,  or  local.  In  addition,  structural  iteration  and 
bookkeeping  variable*  ere  supported. 
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Conclusions#  Remarks 


The  number  and  variety  of  CHDL'a  proooaeo  and  in  use  is 
staggering  ano  this  study  could  net  hope  to  be  exhaustive.  There 
are  at  least  as  many  languages  and  descriptive  systems  worthy  of 
close  study  as  have  been  presented  here.  This  study  has# 
however#  identified  some  truly  useful  languages  and  some  serious 
flaws  in  others.  Language  character  1 st i cs  that  are  important  to 
specific  applications  have  been  discussed.  For  instance#  hop  is 
well  suited  for  driving  code  generation#  TSP  is  bv  far  the  most 
general  end  flexible  language  presented#  recommending  it  for  a 
broad  range  of  applications#  and  SMlTfc  is  easy  to  use  end  well 
suited  for  H*scribing  Behavior  for  emulation. 

In  addition  to  observations  about  individual  lenouagea#  the 
study  has  d*vel ored  and  refined  e  scheme  for  describing  end  com¬ 
pering  languages  that  will  be  useful  for  general  use.  This  would 
be  useful  in  compiling  descriptions  of  a  large  number  of 
languages  for  reference.  A  system  of  description  can  also  halo 
one  see  a  language  mgre  clearly#  aiding  language  desion  ano  se¬ 
lection. 
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Summary  of  language*  *nd  Characteristic* 


The  following  table*  summarize  th#  character  i  *t  i  es  of  the 
procedural  end  non-procedural  language*  **par# t*1v#  *<th  th*  fol- 
1  owl  no  remark*  applying  to  both  table*.  No  Lnguao*  allow*  re- 
nundant  description*  unles*  It  1*  soeclflcly  mentioned.  Ml 
lanouage*  that  provide  *hift  operator*  provide  for  shift*  of  var- 
ylna  size  and  in  both  direction*.  Any  of  tnese  language,  can  be 
extended  by  the  addition  of  new  data  operator*.  *o  tM*  is  not 
mentioned  under  -generality-.  In  .11  cases  the  reader  should 
rely  on  the  main  text  for  more  detail  and  precision,  these  table, 
are  meant  a*  a  short  overview.  The  following  table  defines  some 
of  the  term*  and  abreviation*  used  in  the  summary  table. 
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DEFINITION 


al ternat  i  on 
comb*  net, 
concat , 
control  lad 

deer, 

1  nc  • 

modul ar, 

RT 

selection 
aoec,  level 
Std.  erlth, 

std.  bool, 

std.  rel, 

awl t ,  c 1 r . 


a  construct  analogous  to  IF .. THEN, ,EL$t . . 
combinatorial  network 
coneatenat 1  on 

scopes  ability  to  control  which  modules  may  access 

a  variable 
decrement  operator 
Increment  operator 
modu 1 ar 1  sat  Ion 

register  transfer  level  of  description 
e  construct  snalogeus  to  CASE 
specification  level  of  detail 
standard  arithmetic  operators# 
at  least  ♦  #  -#  **  and  / 
standard  boolean  operators# 

at  least  AND#  OR#  and  NOT 
standard  relational  operators#  at  least 
*»  <#  >#  and  their  inverses 
switching  circuit  level  of  description 
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PROCEDURAL.  LANGUAGF8 
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renaming  renaming  address  renaming 

regl star, 
reneml ng 


ROCEDUfUL  LANGUAGES  (CO^T 


NON-PH'bCFDURAL  LANGUAGES 
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A  Comparative  Study  of  Intermediate 


An  Intermediate  Language  (IL)  represents  a  program  while  it  is  being 
processed  by  a  compiler,  and  allows  communication  of  information  about  the 
program  between  phases  of  the  compiler.  Whether  a  compiler  consists  of  one 
or  of  several  physical  passes,  it  can  be  thought  of  as  a  collection  of  several 
logical  phases.  The  first  phase  (ordinarily  lexical  analysis)  inputs  a 
source  program  and  outputs  some  intermediate  language  program.  Other  phases 
will  accept  an  IL  program  and  output  another,  possibly  in  a  different  IL.  I 

Eventually  some  phase  accepts  an  IL  and  outputs  the  target  language.  The  ! 

form  of  these  ILs,  and  the  information  carried  along  with  them  (symbol  tables,  .j 

data  flow  information,  etc.)  depend  on  the  functions  of  the  phases  that  they 
link.  In  designing  a  compiler,  it  is  often  convenient  to  use  several  ILs, 
and  to  let  their  operators  and  storage  mechanisms  reflect  the  source  language, 
or  the  target  language,  or  both.  ILs  may  be  dependent  on  the  language  struc¬ 
ture,  or  on  the  host  machine  or  both.  These  dependencies  make  it  difficult 
to  retarget  or  adapt  the  compiler. 

The  use  of  a  single,  universal  intermediate  language  has  been  proposed 
to  reduce  compiler  implementation  effort  by  providing  a  standard  interface 
between  the  language  dependent  and  machine  dependent  parts  of  a  compiler 
[Col74].  The  three  major  advantages  of  a  compiler  built  this  way  are:  the 
compiler  can  be  adapted  to  another  language  by  changing  only  the  language 
dependent  phases,  it  can  be  retargeted  by  rewriting  the  machine-dependent 
phases,  and  a  considerable  part  of  the  compiler  (some  optimizations,  symbol 
table  routines,  etc.)  will  be  relatively  constant.  The  major  requirements 
on  a  universal  IL  are  that  it  should  be  independent  of  both  the  source  lan¬ 
guage  and  the  target  machine,  and  that  it  be  flexible  enough  to  represent  all 
the  information  that  has  to  be  communicated  between  phases  of  the  compiler. 

IL  Requirements 

The  first  major  requirement  mentioned  in  the  previous  section  is  that  a 
universal  IL  be  source  language  and  target  machine  independent.  One  result  i 

of  this  requirement  is  that  the  "level",  or  complexity  of  the  operators  and 
storage  descriptions,  of  the  language  be  well  placed  between  the  source 
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languages  and  target  languages  that  we  are  considering.  Two  observations 
motivate  this  requirement.  The  first  is  that  if  the  mismatch  between  the  IL 
and  either  the  source  or  target  languages  is  too  great,  the  corresponding 
translation  will  be  difficult,  and  the  second  is  that  if  the  IL  is  too  close 
to  either  language,  it  will  be  dependent  on  it  to  some  extent.  It  is  diffi¬ 
cult,  if  not  impossible,  to  define  a  fixed,  universal,  intermediate  language 
[HW781.  Take  for  example,  an  implementation  of  FORTRAN  on  the  PDP  11/780 
VAX  machine.  The  high  level  DO  construct  should  remain  a  DO  in  the  IL,  since 
1)  knowledge  of  high  level  control  constructs  aid^  global  optimization  and,  2) 
the  VAX  has  a  single  instruction  which  implements  almost  the  entire  control  of 

DO  loop.  However,  handling  such  a  peculiar  control  construct  (from  a  modern 
language  viewpoint)  makes  the  IL  rather  language  dependent.  Most  ILs  would 
have  it  reduced  to  separate  loop  and  test  elements,  which,  of  course,  are 
both  hard  on  the  global  optimization  and  make  the  use  of  the  DO  instruction 
on  the  VAX  very  hard  to  implement.  For  these  reasons,  a  universal  IL  must  be 
extendible.  Extendibility  will  partially  negate  some  benefits  of  having  a 
single  fixed  IL,  but  it  will  make  the  universal  IL  idea  workable. 

Another  requirement  for  an  intermediate  language  is  that  it  be  able  to 
represent  all  the  information  that  has  to  be  passed  between  the  compiler 
phases  that  it  links.  A  single  IL  is  desirable  so  that  only  a  single  support 
system  to  read,  write,  and/or  analyze  it  will  be  needed,  and  because  a  single, 
convenient  IL  can  provide  a  conceptual  framework  for  the  compiler.  Therefore, 
a  universal  IL  should  be  able  to  represent  not  only  the  semantics  of  the  lan¬ 
guage,  but  also  the  information  required  for  register  allocation,  code  gen¬ 
eration  and  optimization.  It  is  also  desirable  that  the  language  be  suited 
to  the  transformations  required  for  optimization. 

The  level  of  an  IL  results  from  the  selection  of  its  operators  and  con¬ 
trol  constructs,  and  from  its  storage  mechanisms.  Since  there  is  more  common¬ 
ality  among  the  source  languages  we  are  considering  than  among  the  target 
machines,  a  fairly  high  level  representation  for  operators  and  control  con¬ 
structs  is  needed.  Also,  the  retention  of  looping  and  conditional  constructs 


in  the  source  language  allows  the  compiler  to  retain  information  useful  for 
optimization.  As  for  storage  mechanisms,  it  is  important  to  avoid  the  use 
of  specific  accumulator  registers  or  stack  operations  that  are  not  machine 
independent . 
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Languages  Considered 

The  intermediate  languages  considered  in  this  report,  with  a  brief  de¬ 
scription  of  each  follow. 

The  JOCIT  IL  I  Dun75  1 

The  JOCIT  IL  was  developed  for  compilers  translating  J0VIAL/J3  for  a 
number  of  machines.  The  language  is  high  level  and  fairly  language  dependent. 
It  is  a  post-fix  -  polish  language.  Looping  operators  are  included,  and 
symbols  and  their  attributes  are  kept  in  a  symbol  table. 

OCODE  [ Ric71] 

OCODE  is  the  IL  for  Richards'  BCPL  compiler.  It  is  language  dependent, 
has  been  used  to  retarget  the  compiler  to  from  1020  machines  (as  of  1974)  and 
is  not  well  suited  for  stack  machines. 

HALMAT  [ 1174] 

HALMAT  is  the  IL  for  the  Intermetrics  HAL/S  compilers.  It  is  high-level 
and  language  dependent.  It  uses  explicit  temporaries  for  intermediate  re¬ 
sults,  and  is  machine  independent. 

JANUS  [  Co  174,  HW78,  WH78,  CPW741 

JANUS  was  designed  as  a  universal  IL.  It  provides  a  large  set  of  opera¬ 
tors  and  a  flexible  storage  scheme,  and  it  is  extendible.  Its  control  and 
data  structures  are  at  a  fairly  low  level,  and  it  uses  a  stack  for  intermedi¬ 
ate  results.  It  is  designed  so  that  it  can  be  translated  to  assembly  code  by 
a  macro  processor,  and  some  difficulty  in  handling  temporary  variables  and 
its  lack  of  high  level  control  constructs  can  be  attributed  to  this. 
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TCOL  .  t Cat78,  SLN791 
ada 

TCOL  was  designed  by  R.  G.  G.  Cattell  as  a  universal  IL.  The  version 
presented  in  his  thesis  is  sketchy,  and  TCOL  ^  is  an  elaboration  on  it  de¬ 
veloped  by  the  PQCC  project  at  Carnegie-Mellon  University.  TCOL  programs  are 
trees,  with  fairly  high  level  data  structuring  and  control  flow  operators. 
PQCC's  approach  to  universality  is  to  introduce  language  or  machine  dependent 

operators  and  data  structures  as  needed  (TCOL.  ,  is  the  version  tailored  to 

Ada 

Ada)  and  to  let  the  compiler-compiler  produce  a  compiler  tailored  to  that 
version  of  TCOL. 

IL  Comparison 

The  table  in  this  section  gives  the  ILs  mentioned  above,  and  how  well 
each  meets  the  requirements  that  have  been  defined.  The  text  in  this  section 
will  elaborate  on  the  entries  in  the  table. 

1.  Source  and  Machine  Independence 

Since  OCODE,  HALMAT  and  the  JOCIT  IL  were  each  designed  with  a 
particular  language  in  mind,  they  tend  to  contain  assumptions  about  the  source 
languages  operators,  data  types,  parameter  passing  conventions,  etc.  and  so 
their  language  independence  is  low.  JANUS  was  designed  for  language  inde¬ 
pendence,  and  its  use  in  Pascal,  Algol  68  and  BCPL  compilers  confirm  that  this 
goal  was  well  met  [HW79].  TCOL  was  also  designed  to  be  language  independent, 
and  TCOL^ja  was  designed  as  an  IL  for  Ada.  Much  of  the  development  of 
TCOLAcja  was  in  the  specification  of  data  types,  data  structuring  facilities, 
control  structures,  etc.  Since  Ada  has  a  rich  set  of  these  features,  and 
since  TCOL.,  is  at  a  much  lower  level  than  Ada,  TCOL.,  is  fairly  language 
independent.  The  structure  of  the  IL  and  its  external  representation  and 
symbol  handling  are  language  independent. 

The  machine  independence  of  all  these  languages  is  good,  and  all  of 
them  except  TCOL  have  been  used  in  compilers  for  more  than  one  machine. 
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2.  Level 


The  three  language-dependent  ILs  are  at  a  fairly  high  level,  with 
looping,  alternative  and  procedure  call  constructs.  JANUS  has  a  mix  of  high 
and  low  level  features.  Its  control  constructs  are  conditional  jumps,  its 
data  structuring  mechanisms  are  less  complex  than  those  of  TCOL  but  more  com¬ 
plex  than  those  of  most  ILs,  and  its  procedure  call  and  parameter  passing 
mechanisms  are  very  flexible.  TCOL  is  the  highest-level  of  the  ILs  con¬ 
sidered.  Its  control  constructs,  data  types,  data  structuring  methods,  and 


operations  have  more 

flavor  of  Ada 

than  of  a 

machine 

language. 

Jocit  IL 

OCODE 

Janus 

TCOL .  , 
Ada 

HALMAT 

Source  Independence 

Poor 

Poor 

Good 

Fair 

Poor 

Machine  Independence 

Good 

Good 

Good 

Good 

Good 

Level 

High 

High 

Medium 

High 

High 

Temporary  Storage 

Implicit 

Stack 

Stack 

Stack 

Tree 

Explicit 

Temps 

Extendibility 

No 

No 

Yes 

Yes 

No 

Suitability  for 

Code  Generation 

Fair 

Fair 

Fair 

Good 

Fair 

Practical  Experience 

Yes 

Yes 

Yes 

No 

Yes 

Figure  B.l  IL  Comparison  Chart 

3.  Temporary  Storage 

HALMAT  uses  explicit  temporaries  while  the  Jocit  IL  is  a  post-fix 
polish  language  and  so  uses  an  implicit  stack.  Janus  and  OCODE  use  explicit 
stacks  and  TCOL  is  a  tree  language,  with  temporary  storage  implicit  in  the 
tree  structure. 

4.  Extendibility 

With  enough  effort  any  language  is  extendible,  however,  Janus  and 
TCOL  were  designed  with  extendibility  in  mind,  while  the  other  ILs  were  not. 
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5. 


Suitability  for  Code  Generation 


This  is  discussed  in  the  IL  selection  in  Section  3  of  this 

report . 

6.  Practical  Experience 

HALMAT  and  the  Jocit  IL  have  each  been  used  in  commercial  compilers 
for  more  than  one  computer.  OCODE  has  been  used  to  transport  the  BCPL  com¬ 
piler  to  a  number  of  machines,  and  Janus  has  been  used  in  several  compilers 

and  an  experimental  number  of  machines.  TCOL.  ,  has  not  been  used  in  a  com- 

Ada 

piler  to  date,  but  will  probably  be  used  for  one  or  more  Ada  compilers  in 
the  near  future. 
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(M0P  file  for  Mini-S  (simplified  PDP-  8*  Note:  Comments  are  in 

braces  4}. 

4l-flds}[ 

(@p  o  3  o  e) 

(I. BIT  310C) 

(ADR  4800) 

(re. BITS  4800) 

(UBITS  5700) 

(UCLASS  4100)] 

(SBs}[ 

(PC  1  8  P) 

(Mp  256  12  M) 

(Acc  1  12  G) 

(10. REG  1  8  R) 

(L  1  8  R)  ] 

■(AMs}  [ 

Z8:  $  1 :  #8 

%Mp:  (<>  Mp  $1:#8  0  12) 

%@Mp :  (<>  Mp  (<>  Mp  $1:8  0  12)  0  12) 

%PC:  (<>  PC  1  0  8) 

%Acc:  (<>  Ac c  1  0  12) 

%L:  (<>L10  8) 

%I0.REG? (<>  10. REG  108)] 

■OCs}  [ 

Y:  ( 

%8  ::  (EMITC  5  0  0]  $1  0) 

%Mp  : :  (EMIT] 510]  $11)) 

Z:  ( 

%Mp  ::  (EMIT!  5  1  01  $1  0)  from  R.  G.  G.  Cattell  (Cat7l0 

%PMp  : ;  (EMIT!  5  2  01  $1  1)  ) 

C-l 


10:  ( 

%8  ::  (EMIT[ 6  0  03  $1)  )  ] 


[ 

(I-FMTs} 

(FMT  1}  (6P  Z)  }l-opnd  format} 

(FMT  2-)  (0P  Y)  -(jump  format} 

•(FMT  3}  (SP  UCLASS  UBITS)(micro  format} 
•(FMT  4}  (6P  10)  (1ST  format} 

(QC-FMTs} 

-(FMT  5}  (ADR  I.  BIT)  (Y  and  Z} 

(FMT  6}  (10. BITS)  ]  (16} 


(Mops}[ 


('-  %Acc  (AND  %Acc  $  1 : Z) )  :: 

(EMIT!  AND  1  1  I J  0  $1) 

(-  %Acc  (+  %Acc  $  1 : Z) )  :: 

(EMIT[ TAD  111]  1  $1) 

(;  («-  $1 : Z  (+  $1  :Z  1))  (=>  (EQL  $  1 : Z  -1)  (-  $PC  (+  %pc  1))))  :: 

(EMIT! ISZ  111]  2  $1) 

(;  (►  $  1 :  Z  %Acc)  (^  %Acc  0))  :  : 

(EMIT!  DCA  1  1  1  1  3  $1) 

(;  (+■  %L  %PC)  ('  %PC  $1  :Y) )  :: 

(EMIT!  ,JMS  2  111  4  $1) 

(«-  %PC  $1  :Y)  :  : 

(EMIT!  JMP  2  1  1  I  5  $1) 
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(«-  %  10. REG  10)  :: 

(EMITf IOT  All]  6  $1) 

(*-  %Acc  (N0T  %Acc) )  : : 

(EMIT) COMA  3111  7  0  40) 

(■*-  %Acc  0)  : : 

(EMITi  CLRA  3  1  1)  7  0  20) 

(+•  %Acc  (+  %Acc  1))  :: 

(EMIT) INCA  311)  7  0  10) 

(*■  %Acc  (-  %Acc  1))  :: 
(EMIT) DECA  311)  704) 

(*-  %Acc  (I  %Acc  1))  :: 

(EMIT  SLA) 3111  701) 

(NO-OP)  :: 

(EMIT) N©P  311]  700) 

(•*-  %Acc  1)  :  : 

(EMIT) SET1A  311)  7  0  30) 

(*■  ZAcc  2)  : : 

(EMITl  SET2A  3  1  11  7  0  31) 

(<  %PC  %L)  :  : 

(EMITl  RTS  3  11]  7  1  40) 

(*  %PC  %Acc)  :: 

(EMIT) JMPA  311]  7120) 


C-3 


(=>  (LSS  ZAcc  0  )  <♦  %PC  (-1-  ZPC  1))) 


(EMIT!  SKPL  3 

i  n 

7  1 

4) 

(  =  >  (EQL  ZAcc 

0)  ( 

-  %PC  (+  %PC 

I))) 

(EMITi  SKPE  3 

l  1 1 

7  1 

5) 

(=>  (NEQ  %Acc 

0)  («- 

%PC 

(  + 

%PC 

1))) 

(EMITI  SKPNE  3 

i  i] 

7  1 

2) 

(=>  (GTR  %Acc 

0)  (+- 

%PC 

(+ 

%PC 

1))) 

(EMIT[  SKPG  3 

1  1] 

7  I 

1) 

(=>  (LEQ  ZAcc 

0)  («- 

%PC 

(+ 

%PC 

1))) 

(EMITCSKPLE  3 

1  11 

7  1 

6) 

(=>  (GEQ  %Acc 

0) 

%PC 

(+ 

%PC 

1))) 

(EMIT[ SKPGE  3 

1  1] 

7  1 

3) 

MISSION 

of 

Rome  Air  Development  Center 

RAVC  plant,  and  exec utes  research,  development,  test  and 
&  elected  acquisition  programs  In  support  of  Command,  Control 
Communications  and  Intelligence  (C^I)  activities.  Technical 
and  engineering  support  within  are as  of  technical  competence 
Is  provided  to  ESV  Program  Offices  (POs)  and  otheA  ESP 
elements.  The  principal  technical  mission  areas  axe 
communications ,  electromagnetic  guidance  and  control,  sur¬ 
veillance  of  ground  and  aerospace  objects,  Intelligence  data 
collection  and  handling,  information  system  technology. 
Ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


